On Thu, 2011-02-17 at 15:44 +0000, Alistair Miles wrote: > Hi Richard, >
[snip] > If the server supported adding further media resource to the package, you > could advertise this by including an app:collection element within the feed > document, as per [2]. I.e., clients would do a POST to the package-contents > collection URI, as per standard Atom protocol for creating media resources > in a collection. > > If you wanted to delete any media resources within the package, then each > media resource would have it's own URI which you could send a DELETE to. If > you wanted to delete the whole package, you could still do a delete on the > deposit's edit-media URI as specified in the current SWORD protocol spec. [snip] Your comment is along the same lines as what I have suggested (but probably not as clearly). I'm pushing this as an alternative to packaging though. My feeling is it is simpler to spec (hence implement) multiple URIs to represent a package than it is to agree to a metadata format and file structure inside an archive. Ian Stuart's concern is the overhead involved in the multiple HTTP requests that would be required to build up the complex object. (Not that this precludes the fire-and-forget ZIP of all your files approach) This doesn't escape having to agree a data model for what we're moving around though. You have specced a top-level entry containing one file per sub-entry. Experience would indicate you need to have another layer of abstraction to support HTML-formatted documents (one or more HTML files + inline content). I feel like I'm doing a lot of hand-waving so don't want to chew over SWORD in any more depth until Richard has produced the draft. All the best, Tim. ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Sword-app-techadvisorypanel mailing list Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
