[Building Sakai] Migrating Sakai 2 to Sakai 3

Thu Mar 26 03:30:18 PDT 2009

We should also point out the following doc originally put together by  
Steven Marquard:

http://docs.google.com/Doc?id=dcxqdmnm_07b7bkrfk

It outlines a number of migration strategies and some plans/intentions  
for testing a couple of the choices.

On Mar 26, 2009, at 02:10, Clay Fenlason wrote:

> I don't think I share quite the same impression of migration suffering
> (nor, I've found, does my faculty and student advisory committee) at
> the prospect of a UX backed by two Sakai frameworks, but I gather
> we're in a minority.  Still, I think this position merits some further
> elucidation, if not some defense.  It is not unusual for Sakai to make
> inroads in the form of project sites before it achieves buy-in as an
> LMS.  We plan to echo this pattern in a shift from Sakai 2 to "Sakai
> 3" (more below about why I put this in quotes) as well - the
> next-generation product is first experienced as a new site type, the
> sort created for ad hoc purposes, while the course sites continue to
> look and behave like Sakai 2.  This seems to us at GT a far more
> graceful transition - allowing our users to move more at their own
> pace, familiarizing themselves with the new interaction design by
> opting in where they care to, increasingly so as further functionality
> is rolled into place - than a sharp cutover of the entire system and
> an abrupt spike in the training burden and technical risk for full
> data migration, etc.  This actually looks to me like a kind of gradual
> upgrade strategy that never would have been possible with a
> proprietary product, and I once again am thankful for how Sakai
> provides more options.
>
> Before going any further, I'd be remiss in not pointing out that there
> is, in fact, nothing settled on the question of what "Sakai 3" will
> be.  There is no such animal as yet, strictly speaking.  There are two
> very suggestive projects - one for the back-end (K2) and one for the
> front-end (which Nathan has designed, and I'll call '3akai') - which
> are in a state we might call "R&D" if we agree to the sort of process
> Michael has recently surfaced, and which, when joined together, might
> represent in embryonic form what "Sakai 3" will be.  Cambridge and
> Georgia Tech seem perversely determined to risk putting this
> experimental pairing into production before these questions have been
> decided, but that also signals a certain momentum that it would be
> disingenuous to shrug aside.  Not trying to be coy.  Just sayin'.
> "Sakai 3" is a good placeholder indicating some future,
> next-generation product.  There is good progress being made in areas
> that we hope will eventually lead to a general Sakai 3 release, but
> much remains to be worked out, and no one's in a position to be making
> any release claims just yet.

This is an excellent description. I would say that K2 and 3akai are  
the two projects that right now form the basis for what the foundation  
hopes and intends will eventually be Sakai 3. More projects need to be  
created and eventually combined with these for that to happen on the  
envisioned schedule.

>
> As to "tools," the notion itself is somewhat suspect, and for the most
> part will need to be taken on a case-by-case basis.  No one has yet
> wrestled with all these cases.  We can hold out hope for a general
> mechanism for tool and component porting (e.g. a K1-K2 compatibility
> layer, which some seem prepared to chase down, and that would be a
> pivotal development) but apart from that unrealized prospect some of
> the considerations throughout will be:

Again, the document referenced above is a good resource.

>
> a)  Is the tool simply obviated in its capabilities by the basic
> interaction design of page authoring and assembly?  The legacy
> "Syllabus" would be one obvious sort.  There may be less obvious sorts
> that could have their goals satisfied by page templates.
>
> b)  Is the tool really better understood as a general capability
> (perhaps collapsing several "tools" onto a shared service) which can
> support a variety of widgets better tailored to particular use cases?
> Assignments, I'm looking at you ... of course imho.

I think mailtool/email archive/announcements are candidates for this  
approach as well.

>
> c)  How does the functionality in question treat its core data, and if
> it's not as "content," should it be reimagined (and then
> re-developed)?  And I believe the answer to the latter will be "yes"
> more often than one might think.  I'd posit that what we currently
> think of as the Gradebook is perhaps a surprising yet pedagogically
> deep case of precisely this sort of thing.
>
> d)  Is the tool however so complex and critical that we need to work
> out a way to run it in legacy form until we get it sorted out in all
> its next-generation glory?  Again, a preferred strategy would be a
> general compatibility layer for all tools, but if that doesn't get
> worked out we may need to look at targeted ports for especially tough
> cases (e.g. Gradebook or Tests & Quizzes).  Or maybe the tool
> basically runs its own stack anyway (evaluation?) and can continue on
> in that fashion.

The fewer of these the better. But I think we are naive to assume we  
won't need to do this in at least a few places for a year or two.

>
> ... and so forth.  I don't mean to be alarming, but then neither would
> I want to underestimate the challenge.  There will be options and
> mitigating strategies (running two frameworks in parallel along with
> the rest), but a great deal of thought is going to be called for in a
> large number of cases.
>
> I think there is a particularly strong need for the K2 project, if it
> hopes to become the platform for Sakai 3 development, to document how
> tool and component developers can work against it.  And we won't start
> to have satisfactory answers to the sorts of questions you're asking,
> Sean, until those laboring to achieve a *working* K2 in the next
> several weeks can start to turn more attention to polishing off a
> *usable* K2 for tool and component developers.
>
> ~Clay
>
> On Wed, Mar 25, 2009 at 6:45 PM, Sean Keesler <sean at keesler.org>  
> wrote:
>> I was reading the Sakai3 proposal and came across this under the  
>> plans for
>> 2010:
>>
>> A “hybrid” mode will be available. It will allow Sakai 2 and Sakai  
>> 3 to run
>> side by side and appear as single system to users. Configuration  
>> settings
>> will allow you to
>> determine which capabilities are drawn from Sakai 2 and which are  
>> drawn from
>> Sakai 3.
>>
>> That isn't very far in the future.
>> I imagine that there will be a reasonable group of new schools that  
>> will
>> decide to wait until Sakai 3 before they begin a Sakai  
>> implementation so
>> that that they don't need to run two systems or suffer the migration.
>> Has there been any discussion about which Sakai 2 tools will be  
>> "migratable"
>> to Sakai 3? Are there features that can be built into Sakai 2 tools  
>> now to
>> ensure that their data can be migrated to 3?
>>
>>
>> -- Sean
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
>> with a subject of "unsubscribe"
>>
>
>
>
> -- 
> Clay Fenlason
> Director, Educational Technology
> Georgia Institute of Technology
> (404) 385-6644
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"

-- 
Michael Korcuska
Executive Director, Sakai Foundation
mkorcuska at sakaifoundation.org
phone: +1 510-931-6559
mobile (US): +1 510-599-2586
skype: mkorcuska