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. For example, for the University of Oslo, I'm working on a library to serialise and deserialise BagIts which conform to the profile required by the project: https://github.com/nye-duo/BagItLibrary This is independent of the repository implementation, so I have then written a packager for DSpace which uses this library to stitch the generic knowledge of the package format to the DSpace API and DSpace SWORDv2 implementation. The "sword packagers" project that I imagined would initially only, therefore, be useful for DSpace users, but it would be good to see the equivalent work for other platforms. What I'd really hope to see is some consensus across clients and servers as to the most useful package formats, which is more likely to be achieved if there are implementations of those formats for the respective server environmetns. >> By doing something practical, rather than working on a more abstract >> package registry, we might learn enough about the problem space and >> the package formats which are in common usage to bootstrap a package >> registry off of it (or maybe we won't even need to). >> > > Agreed, in my attempt to understand I described what is basically an abstract > package registry. I still think such a thing would be very useful but I > acknowledge what you say about concerted effort. Yes, I definitely agree it would be useful. The problems here are also not purely technical, but also social - getting people to use a registry, getting the documentation for the formats, minting appropriate uris, and all those other things which are technically easy but surprisingly hard to get done. > I also agree that gaining experience with a few commonly used package formats > is a useful approach, and I'd be happy to contribute to that body of > knowledge. I suppose that implementing simple use cases in my own environment > and share the results is the best way to start that. Yes, that would be great. We need to start to build up a body of work around this problem, and then we can formalise our approach to it later :) Cheers, Richard -- Richard Jones, Founder, Cottage Labs t: @richard_d_jones, @cottagelabs w: http://cottagelabs.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
