On 18/02/11 12:05, Tim Brody wrote: > 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)
I /think/ that several of us are talking across several cross purposes, but I'm not sure. I think there are three types of sword conversations to open the proceedings: 1) "Hello server, I'd like to deposit this" 2) "Hello server, tell me about item 12345" 3) "Hello server, please update item 12345 with this data" In the first situation, the server responds with "Thank you. For future reference, the item is here. You can also edit the item there" With the second scenario, the server responds with "I have it. You can see it here, and modify it there" The third scenario directs the server to modify immediately, and the server would respond with "Thank you, I have successfully done that. You can see it here, and modify it there" My concern is the number of times the server & client talk before a transfer completes... and I'm coming from the position that transfer is a common & frequent task: a multiple of items each day, and each item to a multiple of locations. For an occasional transfer, on a one-to-one basis, then a conversation is fine. Once the numbers start to climb, things need to become briefer & briefer. The thing that interests me, however, is not the client-server conversation (per sae), but what happens when the client actually gets to send a record to the server. I'm interested in how we transfer the information about the files, their relationship to each other as well as the record, and the records metadata. I'm interested in how we package that information up & send it over. I'm interested in how/where the conversation happens to work out what the package is or contains. SWORD is a transport mechanism... we all understand that - but sword can either be a bling truck (http://farm1.static.flickr.com/120/307424194_ccb7df1246.jpg) or a container (http://www.shipping-container-modification.com/images/standard_large.jpg) One is universal & useful. One is really pretty, and useless :D -- Ian Stuart. Developer: Open Access Repository Junction and OpenDepot.org Bibliographics and Multimedia Service Delivery team, EDINA, The University of Edinburgh. http://edina.ac.uk/ This email was sent via the University of Edinburgh. The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ------------------------------------------------------------------------------ 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
