...
Should an importer save the exact original package file in a bitstream in the item it creates? A symmetric exporter *should be able to to recreate an exactly equivalent package. ANSWER: esolve Resolve this case-by-case, but generally do NOT save the package because it might be huge.
- The manifest file that comes with a package is recorded in a itstream Bitstream like the content files. Since it is actually metadata, there ought to be a way to indicate that in the item. For DSpace 1.x we can put it in a "METADATA" bundle, but this breaks down in DSpace 2 if bundles go away. ANSWER: Put it in the METADATA bundle , -- the bundle name is still significant as a tag on the bitstream. Also set
BitstreamFormat
to identify the particular manifest type. - Is it worth implementing export of Collections and Communities, or should that be taken out of the interface? The implementation of a packager may choose not to support anything but Items.
- RobertTansley wants to see more separation between importer and exporter, since we don't always need both. A
Packager
doesn't have to implement bothimport
andexport
methods. Is it worth adding explicitPackageImporter
andPackageExporter
interfaces as subclasses ofPackager
so each packager could implement whichever it wants (or both). That would let the code detect which ones are importers before getting an exception trying to import, so it could post a list of package importers (and the same for exporters, of course). --lcs DONE. Separate interfaces.