[Building Sakai] Investigating site exports from Sakai 2

[Steve Swinsburg]

There's probably others that may not be watching that are using it  
with local/contrib tools and find their app breaks, so best to just  
mark ArchiveService.archive() as deprecated and create a new API,   
ExportService perhaps.

cheers,
Steve


On 30/09/2009, at 11:54 PM, John Leasia wrote:

> We use it occasionally here at UM. Mostly for support these days,  
> but also we've had some instructors move from other Sakai  
> institutions to UM and they brought some class site content with  
> them via archive/import.
>
> John
>
> Speelmon, Lance Day wrote:
>> Okay - after some more investigation, I have reached the following  
>> conclusions.  I have yet to hear about anyone depending on  
>> ArchiveService.archive().  If I continue to hear nothing, I will  
>> have to assume no one is using it.
>>
>> Based on sakai-2.6.0 artifacts, I believe the following to be  
>> accurate. This tells us that services that claim to support  
>> ArchiveService.archive() should export to XML(/ZIP?) but need to be  
>> tested. Those services which do support transferCopyEntities() but  
>> do not support archive() are the obvious gaps that need to be  
>> filled; e.g.: GlossaryEntityProducer, GradebookEntityProducer,  
>> MatrixContentEntityProducer, MetaobjEntityProducer,  
>> PresentationContentEntityProducer, SAMigo- 
>> >AssessmentEntityProducer, and WizardEntityProducer. With those  
>> gaps filled, we would at least reach parity with the tools that  
>> currently support copying site structure from one site to another.  
>> This summary only includes tools and services which ship with Sakai  
>> 2.6.0 and do not account for contrib or other third party tools.
>>
>> See: http://confluence.sakaiproject.org//x/jgL5Aw
>>
>> Remaining questions:
>> Does anyone actually depend on ArchiveService.archive()? My  
>> instincts tell me no since most of the tools do not implement it.  
>> Am I wrong?
>> Could we usurp the ArchiveService.archive() interface and change  
>> the behavior so that only site structure is exported without  
>> student content?
>> Do we leave ArchiveService.archive() alone and create a new API?  
>> Probably harder to get into a soon to be released Sakai (e.g. Sakai  
>> 2.7.0).
>>
>> Lance Speelmon
>> Scholarly Technologist
>>
>> On Sep 22, 2009, at 10:26 PM, Speelmon, Lance Day wrote:
>>
>>> I would greatly appreciate your input regarding exporting Sakai 2  
>>> sites to XML.  See:
>>>
>>> http://lancespeelmon.wordpress.com/2009/09/22/investigating-site-exports-from-sakai-2/
>>>
>>> Key questions:
>>>
>>> Does anyone actually depend on ArchiveService.archive()? My  
>>> instincts tell me no since most of the tools do not implement it.  
>>> Am I wrong?
>>> Could we usurp the ArchiveService.archive() interface and change  
>>> the behavior so that only site structure is exported without  
>>> student content?
>>> Do we leave ArchiveService.archive() alone and create a new API?
>>> How many tools still need to implement archive()?
>>>
>>> Thanks, L
>>>
>>>
>>> Lance Speelmon
>>> Scholarly Technologist
>>>
>>> On Aug 17, 2009, at 4:53 PM, Speelmon, Lance Day wrote:
>>>
>>>> As we prepare to start working on a Sakai 2 -> Sakai 3 migration  
>>>> effort, I would like to help organize community contributions.   
>>>> There are a number of roles and skills that need to be filled and  
>>>> your participation would be highly valued.
>>>>
>>>> What can be done immediately:
>>>>
>>>> 1) Collaborate on defining the migration project plan.
>>>> 2) Investigate LTI as an underlying mechanism for exposing Sakai  
>>>> 2 tools within the Saki 3 portal.
>>>> 3) Investigate Moodle's export/import architecture and file  
>>>> formats.
>>>> 4) Develop a Sakai 2 Resources (i.e. ContentHosting) to Sakai 3  
>>>> JCR data conversion.
>>>>
>>>> If any of these tasks sound interesting or you have other ideas  
>>>> you would like to share, please use the wiki space below.  Please  
>>>> take the time to declare your area of interest on the  
>>>> Contributors page.
>>>>
>>>> http://confluence.sakaiproject.org/display/KERNDOC/Migration
>>>>
>>>> Thanks!  L
>>>>
>>>>
>>>> Lance Speelmon
>>>> Scholarly Technologist
>>>>
>>>> _______________________________________________
>>>> 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"
>>>
>>> _______________________________________________
>>> 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"
>>
>>
>> _______________________________________________
>> 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"
> _______________________________________________
> 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"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20090930/87f1e670/attachment.html