Monday, January 30, 2006, 2:16:58 PM, Joe Gregorio wrote:
> I don't think this behaviour is in any way "obviously in violation" > of the atom syntax rules since the server had no way of > determining if the incoming atom:id is universally unique to > begin with, nor does it know the 'intent' of the author, which > may be that a new atom:id should be generated: > http://www.imc.org/atom-protocol/mail-archive/msg02515.html It depends on the semantics of the POST operation. I'd like to know more about the lifecycle of an entry. I had thought that the entry is "created" as soon as it is created/conceived offline, and the POST operation just tells the server about it. The other way of looking at it is, that the entity body of the POST request is just a prototype representation and the entry is "created" by the server after the POST request. Reading the draft more carefully, perhaps the second option is the closest? What can be said of the original POSTed representation then? Is it a representation of a dummy entry, only relevant whilst the entry is being edited offline (but would still require a globally unique id). Or is it a representation of nothing - if so what is the atom:id identifying? If the POST request always creates a new entry, then surely the server must always assign a new atom:id to the entry. Therefore it is wrong for a client to attempt an import operation using a POST, as it will always result in a new identical entry being created (with a different id). So if an import operation is required, then another request type is needed. Does the protocol need mustUnderstand extensions to add a new request type? Furthermore, if we agree that the atom:id of the POST request identifies something, then could we define the model such that the atom:id identified something that would allow servers to implement idempotent POSTing? Apologies for the philisophical rambling, but I think it is important to understand the entry life-cycle in order to understand how the POST request is expected to behave. Any thoughts? -- Dave
