[Building Sakai] Investigating site exports from Sakai 2

[Robert E. Long]

Lance,

I actually use the ArchiveService.archive() method in an application I  
wrote for our university that gets all files from the site, zips them  
up, and moves them to our SAN for archiving purposes. The method is  
used in my application to grab all of the files and .xml files and put  
them into each site's own folder. I wrote some code that reads  
the .xml files and renames the previously retrieved files from the  
system generated filenames to the original filenames.

I would appreciate not having to write my own archiving methods, but  
if it is important that ArchiveService.archive() be scrapped, I guess  
I will have to...

My vote is to keep the existing one and create a new API.

Thank you,
Bob


---+---+---
Robert E. Long, MA
Saginaw Valley State University
Open Source Programmer / Analyst
Math / Education Instructor
M.A. Instructional Technology
O: 989.964.2245

On Sep 29, 2009, at 8:05 PM, 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"

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