[Building Sakai] Investigating site exports from Sakai 2

Charles Hedrick hedrick at rutgers.edu
Fri Oct 9 06:49:47 PDT 2009 

I agree. I am very concerned about the fact that we can't currently  
export a user's content. I'm hoping that the Sakai 3 migration work  
will provide a way to do that, but I consider it a bug if student  
content isn't also include (perhaps optionally). It has two problems:

* We can't use it as a way for faculty to back up their site.
* Faculty will need access for several years to the original site, in  
case there are any questions later about student grading or conduct.

I've always felt that there are a set of things a tool needs to  
implement before we even accept it as contrib. One is exporting  
content. As a tool developer who hasn't done that, that's going to  
mean really good documentation on how to support copying a tool to a  
new site and how to produce an export.


On Oct 8, 2009, at 12:29 PM, Adam Marshall wrote:

> sorry for coming in late on this one but is there a proposal to let  
> the users save the XML on their desktop? This is something we'd like  
> to do now.
>
> adam
>
>
>
> From: sakai-dev-bounces at collab.sakaiproject.org [mailto:sakai-dev- 
> bounces at collab.sakaiproject.org] On Behalf Of Speelmon, Lance Day
> Sent: 08 October 2009 15:32
> To: sakai-dev List
> Subject: Re: [Building Sakai] Investigating site exports from Sakai 2
>
> FYI - If you are interested to see what Sakai 2.6.0 produces when  
> archive() is run on a site, I have updated this page with a sample  
> zip file and individual XML samples:  http://confluence.sakaiproject.org//x/jgL5Aw
>
>
> Lance Speelmon
> Scholarly Technologist
>
> On Oct 7, 2009, at 3:53 PM, Speelmon, Lance Day wrote:
>
>
> Okay - after some further investigation, it appears as though archive 
> () does not export student content in most cases (the exception  
> being Assignments (so far)). This is good news and means that we  
> will be able to use archive() as-is; likely with some improvements  
> after further testing.  L
>
>
> Lance Speelmon
> Scholarly Technologist
>
> 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:
> 1.       Does anyone actually depend on ArchiveService.archive()? My  
> instincts tell me no since most of the tools do not implement it. Am  
> I wrong?
> 2.      Could we usurp the ArchiveService.archive() interface and  
> change the behavior so that only site structure is exported without  
> student content?
> 3.      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:
>
> 1.       Does anyone actually depend on ArchiveService.archive()? My  
> instincts tell me no since most of the tools do not implement it. Am  
> I wrong?
> 2.      Could we usurp the ArchiveService.archive() interface and  
> change the behavior so that only site structure is exported without  
> student content?
> 3.      Do we leave ArchiveService.archive() alone and create a new  
> API?
> 4.      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"
>
> _______________________________________________
> 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/20091009/80fa28ed/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2421 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20091009/80fa28ed/attachment.bin

More information about the sakai-dev mailing list