On Mon, 21 Mar 2011 21:17:32 -0000, Richard Jones <rich...@oneoverzero.com> wrote:
> Hi Tim, > [snip] >> I just echo what Dave Tarrant has said about talking in real-time with >> this. I can see Richard has injected ideas from various sources into the >> spec. but these ideas need to be thrashed out between multiple brains. I >> was initially thinking we want to add behaviourial controls through >> headers >> whereas I'm more convinced now that these should be IRI parameters, >> which >> will make it more obvious that this IRI is going to behave differently >> to >> the base IRI. > > Can you give us a few examples of what you imagined? POST http://myrepo.org/app/workspace?suppress_metadata Content-Type: application/msword ... POST http://myrepo.org/app/workspace?suppress_metadata&unpack Content-Type: application/zip ... My rationale for this is two-fold: 1) The IRI (base+query) defines the behaviour and can be exposed using rel-links. 2) HTTP headers feel like they're the wrong level for controlling application behaviour. It doesn't seem elegant to express an HTTP request where behaviour is controlled through both the METHOD+IRI and HTTP headers. Conceptually headers like Content-Type are describing the payload whereas Suppress-Metadata is explicitly telling the server to do something with the payload. (NB I think we should be asserting extract-metadata instead of suppress-metadata. The default behaviour of extracting metadata may be more useful but it feels wrong to be asserting a negative - otherwise a client could end up having to suppress-printing, suppress-emailing, suppress-conversion-to-pdf etc. etc.!) I strongly feel In-Progress should be an Atom category. Using a header, clients can't ascertain whether an item is "in-progress", which means clients can't be stateless and in addition have no mechanism to verify the server is treating the collection as "in-progress". In-Progress as a header is also ambiguous in scope: POST contents/ <atom:entry> In-Progress: true ... PUT em-uri/ <application/msword> ... Does that mean the <atom:entry> is no longer in-progress? And last nail in the coffin ... how does a client make an entry no longer in-progress? Very weird semantic to perform a no-op edit (PUT) to change the state of an entry! -- All the best, Tim. ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Sword-app-techadvisorypanel mailing list Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
