Hi all, A few updates -- we discussed this proposal in yesterday's DSpace developers meeting. It was unanimously voted (5 votes in favor during meeting, and 2 more via email) to add this code to Trunk in preparation for 1.7.
However, Richard Rodgers has voiced a concern about one small API change in the current code. Essentially, the code creates a new WorkspaceItem.create() method which allows one to specify a Handle for the newly created WorkspaceItem (and obviously its referenced Item). Richard's excellent point is that we've never allowed objects to receive handles until they achieve "in archive" status. This code change obviously goes against that idea, as a WorkspaceItem is not yet in the archive. -- Extra Details (for those interested) -- Tthe reason behind this WorkspaceItem code change (if it is not obvious already), is that when restoring contents from an AIP, it is necessary to restore the Handle of those original contents (for a full restore to take place). So, when restoring an Item, the handle should also be restored. One route is to restore the item's handle on creation of the WorkspaceItem. Another route is to wait and restore the handle at the point where InstallItem.installItem() is called (though if the Item should ever need to go into a Workflow approval process, this becomes a bit harder to do, unless the handle is known to the WorkflowManager). Richard & I are investigating best routes forward, and whether there are any reasons a restored Item should ever be allowed to enter a workflow approval process. Feel free to comment, if you are interested. -- End Extra Details --- In the end, I don't think this should pause the movement of this code into Trunk. This investigatory work can take place either way, and we will ensure it comes to a suitable resolution very soon (likely in the next few days or week at most). I'll be working to move this code to Trunk over the next few days. I'll also work with Richard to resolve the concerns that he's brought up, and make sure a resolution is also committed soon. Let me know if there are questions/comments! - Tim On 8/10/2010 12:55 PM, Tim Donohue wrote: > All, > > I'd like to officially propose adding the AIP Backup/Restore work to > DSpace Trunk in preparation for the DSpace 1.7 release. > > For full background on this work (including a link to my talk at OR10), > see: > https://wiki.duraspace.org/display/DSPACE/AipBackupRestorePrototype > > In general, this work mostly affects the Packagers > (org.dspace.content.packager.*) and Crosswalks > (org.dspace.content.crosswalk.*). The changes to Packager classes are > major, but are necessary in order to support true 'restores' of content > from AIPs. All existing packagers have been refactored to support the > necessary interface changes. > > There are some changes necessary to the core API as well (but, I've > worked to minimize them), as well as some minor refactoring to SWORD and > LNI (as they both utilize the Packager interfaces). Full details of the > reasoning behind all changes (along with full patches you can view) are > here: > > https://wiki.duraspace.org/display/DSPACE/AipCoreAPIChanges > > I've also written up a detailed description of the AIP format here: > > https://wiki.duraspace.org/display/DSPACE/DSpaceAIPFormat > > Finally, an update on latest status: > > (1) This AIP work has been tested, and can perform basic > restores/replaces of all contents (Community/Collection/Items). It does > *not* yet restore Groups/People/Permissions, but that work is coming. > > (2) This AIP work will receive much more testing as the DuraCloud pilot > starts up in mid-September. DuraCloud pilot partners using DSpace will > be told how they can test this AIP functionality to backup & restore > their DSpace contents to/from DuraCloud (However, it's worth noting this > AIP code is not specific to DuraCloud -- you can just as easily > backup/restore your AIPs to/from Tape, harddrive, etc) > > (3) More work will be ongoing to improve the AIP code (and improve upon > the current AIP format). However, I'd prefer this further development > work move to Trunk, as this code is currently in a stable state (and at > a logical place to merge over). > > (4) This code has already been merged with the Unit Testing work now on > Trunk. No tests seem to have broken during the merge -- but, it's very > likely more tests will need to be added based on the minor core API > changes. > > Questions / Comments? I'll leave this open for discussion/voting until > we can come to some sort of consensus as to whether this is approved to > add to Trunk. I'm hoping this should be 'non-controversial', but I'd > obviously appreciate hearing any feedback or concerns you may have. > > - Tim > ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
