On Thu, May 24, 2012 at 11:33 AM, Richard Jones <rich...@cottagelabs.com>wrote:
> Hi Mark,
>
>
> >> https://bitbucket.org/richardjones/sword-packagers
> >>
> >> I would like to migrate these to the swordapp project on github, and
> >> restructure the project so that it would be easy for others to
> >> contrib
> >> their own packager plugins. Probably each plugin would be its own
> >> maven project, and they could be included as modules in an overall
> >> "sword packagers" maven module. Open to other suggestions though.
> >
> > This looks interesting and useful, and a good way to add more package
> formats to Java applications. Would you welcome plugins in other languages
> that might integrate easily with SWORD client and servers not written in
> Java (I'm thinking of python, for example)?
>
> These plugins are specifically for DSpace because they conform a) to
> the SWORDv2 for DSpace plugin interface, and b) the DSpace API.
>
> I'm not sure how you would go about writing packager plugins for SWORD
> without having a specific server-side implementation in mind. There
> could be some scope in encouraging the community to write software
> wrappers around package formats, which are generic and open enough to
> be widely used, such as a number of people (including myself) on this
> list are doing with BagIt.
>
I think that for the Java case, at least having a strategy for "parsing"
the contents of the package into a reasonable structure and being able to
reference portions of that structure from some specific manifest technology
references. This does make me think of adoption of a tool like VFS or the
like. (http://commons.apache.org/vfs/). Which would give the underlying
provider a common API and referencing mechanism to interact with package
contents:
For instance, say that we have a temp directory the package zip is uploaded
to
zip:file:///tmp/sword/temporaryfile.zip!mets.xml
zip:file:///tmp/sword/temporaryfile.zip!file1.ext
zip:file:///tmp/sword/temporaryfile.zip!file2.ext
Or if its gzip or bzip
tgz:file:///tmp/sword/temporaryfile.tar.gz!mets.xml
tgz:file:///tmp/sword/temporaryfile.tar.gz!file1.ext
tgz:file:///tmp/sword/temporaryfile.tar.gz!file2.ext
Or that the pdf is uploaded to
file:///tmp/sword/temporaryfile.pdf
Perhaps a representation can be made for the atom entry as a manifest.
The general idea would be that the archive encapsulation format be made
more of a SWORD feature, while the Manifest evaluation might still be very
implementation centric.
Mark
--
[image: @mire Inc.]
*Mark Diggory *(Schedule a Meeting <https://tungle.me/markdiggory>)
*2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010*
*Esperantolaan 4, Heverlee 3001, Belgium*
http://www.atmire.com
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
sword-app-tech mailing list
sword-app-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sword-app-tech
