The moral of the story is simple: clients need to know what they're getting into.
1. Servers can accept or reject whatever they want. 2. it's really nice if servers let client's know up front what they intend to accept or reject 3. at this point there's no need for any kind of handshake protocol to determine what a server will accept or reject. What's most likely to happen (and most likely to actually be used and work effectively) is that server's will put up websites [1] that document exactly how their endpoints work and what clients should expect. - James [1] http://code.google.com/apis/gdata/ Antone Roundy wrote: > > I'm not subscribed to the APP mailing list, so hopefully this isn't all > redundant: > > On 12/15/06, Lisa Dusseault <[EMAIL PROTECTED]> wrote: >> A model where servers aren't required to keep such information won't, in >> practice, allow that kind of extension. If clients can't rely on their >> markup getting stored, then clients can't extend Atom unilaterally >> using XML >> markup. > > There are two different issues here, which I think has been mentioned, > but which might bear being clearly stated: > > 1) Do servers have to keep all extension data? > > 2) Can a server accept an entry while discarding some or all extension > data, or do they have to reject the entry and return an error code? > > I think the answer to the first question is clearly no--servers > shouldn't be required to store all arbitrary data that is sent to them. > So the questions are: > > 1) Which hurts more--data loss or rejected entries? > > 2) Is there any way to reduce that pain? > > The pain of data loss is obvious--the data is lost. The pain of > rejected entries is having to fix and repost them or decide not to try > again. > > In either case, it might be useful to be able to query the server > somehow to find out what it will and won't preserve. If data is > discarded, you can figure that out after the fact by loading the > resulting entry and checking whether the data is all there, but one > might prefer to know ahead of time if something is going to be lost in > order to be able to decide whether to post it or not. If the entry is > just going to be rejected, unless there's a way for the server to > communicate exactly which data it had issues with, fixing the data to > make it acceptable could be extremely difficult ("Hmm, I'll leave this > data out and try again...nope, still rejected. I'll put that back in and > leave this out...nope. I'll take both out...nope. I'll put both back in > and take yet another piece of data out..."). > > So, how might a client query a server to see what it will preserve? A > few possibilities: > > 1) Have some way to request some sort of description of what will and > won't be preserved and what might be altered. I don't know how one > would go about responding to such an inquiry except to basically send > back a list of what will be preserved, including some way to say "I'll > preserve unknown attributes here", "I'll preserve unknown child elements > (and their children) here", "I'll store up to 32767 bytes here", etc. > If there is any known extension markup that a server wants to explicitly > state that it won't preserve, there may need to be a way to do that too. > > 2) Have a way to do a "test post", where one posts the data one is > considering posting (or something structurally identical), but says > "don't store this--just tell me what you WOULD store". The response > could include what would be returned if one were to load the data after > it being stored, or it could be some sort of list of anything that would > be discarded or altered. > > 3) (I get the impression this could be done without requiring > changes--is this the sort of process that has already been selected?) > Post the data as a draft, reload it to see if it's all still there. If > so, or if what has been preserved is acceptable, change it's status to > "published" or whatever it's called. If not delete it and give up or > take whatever other action is appropriate. > > > My impression is that data loss would be less painful and more easily > dealt with than rejection of entries that won't be completely preserved. > > ...but I haven't followed the discussion, so what do I know. > >
