Friday, October 28, 2005, 12:59:04 AM, you wrote:
> What are the key remaining issues that need to be settled? > 1. Introspection > 2. Publishing controls (including pub:draft and pub:significant) > 3. Error reporting format > 4. The value of atom:id on posted entries > 5. Traversal/List/View templates > 6. Any thing else? Are we interested in doing anything about idempotent POSTing and preventing duplicates when the client has to retry? It has been raised a few times eg [1]. Assuming "The network is reliable", is a poor practice even in browser applications [2]. I really think that we should try to do something to tackle this in Atom. With mobile applications it is likely to be particular problematic. Even if we don't make such a feature core, we should consider it and ensure that it is possible to add as an extension to the protocol. It is quite a tricky problem. Some techniques to avoid it require the client to contact the server to reserve a posting URL to PUT to. This only works when posting URLs are a cheap resource (eg a GUID in query string), but Atom allows servers to servers to provide pretty URLs based on the Name header, and such URL's are not cheap resources. Another option is to use a Message-Id header or field. This raises the question of who generates the Message-Id. A server generated id is more reliable, but it requires an extra round trip. Clients might use naive algorithms if they are left to do it. A compromise could be to use a hybrid approach where the server generates a prefix for the client, and the client adds a suffix to produce its own ids. The client could then keep the prefix between sessions if it wanted, which would avoid much concern about extra round trips. [1] http://www.imc.org/atom-protocol/mail-archive/msg01686.html [2] http://www.mnot.net/blog/2003/09/13/click_submit_only_once -- Dave
