Ok, I am throwing this out there for the sake of argument... Could a server not issue a unique "stub" id with introspection? Then a client could just increment on the end of that. Ids could be globally unique and a server could change it or not when receiving a POST.
- Luke On 10/16/05, Bill de hÓra <[EMAIL PROTECTED]> wrote: > > Tim Bray wrote: > > > > On Oct 15, 2005, at 6:24 PM, Joe Gregorio wrote: > > > >>> When you POST/PUT an atom:entry in the APP context, it is plausible to > >>> think that we could specify things in such a way that that atom:entry > >>> is not in fact conformant to all the rules of atom-format; i.e. it's > >>> an atom:entry but it's not an Atom Entry Document. > >> > >> > >> Agreed, this is a big issue that does need to be discussed. It may make > >> parts of the protocol easier to implement if we don't require valid > >> Entries on POSTing. One example is leaving off the atom:id > > > > > > Hmm, in fact it seems positively perverse to require clients to > > generate atom:id values with Atom's stringent uniqueness constraints, > > when servers are typically better qualified to do this. So I would > > expect it would be a very common pattern for the initial entry POST to > > omit atom:id, which I think means it's not an Atom Entry Document. > > > > Or am I missing something? -Tim > > > This is a model for a scenario where the server issues the format atom:id: > > > Client Server > | | > | POST /to-some-controller-URI | > |------------------------------------------>| > | | > | 201 created | > | Location: http://example.com/nu-entry | > |<------------------------------------------| > > > Client Server > | | > | GET /nu-entry | > |------------------------------------------>| > | | > | 20O Ok | > | | > | <entry><id>urn:foo/6</id>...</entry> | > |<------------------------------------------| > > > ...clickety click click... > > > Client Server > | | > | PUT /nu-entry | > | | > | <entry><id>urn:foo/6</id>...</entry> | > |------------------------------------------>| > | | > | 20O Ok | > |<------------------------------------------| > > > > If traffic overhead is a concern, this optimization will mitigate: > > > Client Server > | | > | POST /to-some-controller-URI | > |------------------------------------------>| > | | > | 201 created | > | Location: http://example.com/nu-entry | > | | > | <entry><id>urn:foo/6</id>...</entry> | > |<------------------------------------------| > > > ...clickety click click... > > > Client Server > | | > | PUT /nu-entry | > | | > | <entry><id>urn:foo/6</id>...</entry> | > |------------------------------------------>| > | | > | 20O Ok | > |<------------------------------------------| > > > > If clients can be trusted to emit ids you can have some flexibility in > the exchange set the first time something is created on the server, > because you can optimize the handshake over atom:id: > > > ...clickety click click... > > Client Server > | | > | POST /to-some-controller-URI | > | | > | <entry><id>urn:foo/6</id>...</entry> | > |------------------------------------------>| > | | > | 201 created | > | Location: http://example.com/nu-entry | > |<------------------------------------------| > > > Whatever way this is laid out you have to deal with: > > 1 lost-updates and/or merging scenarios > 3 the fact that clients always initiate exchanges in HTTP > > (I had a 2, but forgot it). > > > I've found network clients to generally suck at id generation - people > do nutso things like issuing autoincrementing pks (if you don't know why > this a is a bigger problem that servers doing it, you must only have one > client). That's why HTTPLR recommends only servers issue ids (an earlier > rev had a profile for client issuance but I dropped it). Maybe client > MUAs suck less, I don't know a whole lot about mail. That said, If we > are going to allow or encourage clients to create IDs, then we are going > to spec an algorithm so they don't screw it up. > > cheers > Bill > >
