[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: issue: Collection Document Fidelity


Joe Gregorio wrote:
On Thu, 17 Mar 2005 11:24:19 -0800, Ezra Cooper <ezra@xxxxxxxxxxxx> wrote:

Obviously there's an issue here in how to specify DELETE.

How about something along the lines of, "In response to a DELETE, the server
SHOULD remove the resource from any collections which it controls." This way
you know what to expect from DELETE, although there's some possibility that
the member does not actually get removed from some collection somewhere.



And this doesn't even have to have anything to do with the URI structure
and jumping off to different servers. If 'users' are to be managed by
collections
wouldn't it be logical that there's cases where one user couldn't DELETE
another user? Or how about a 'categories' list that is fixed for a weblog.

Joe and I discussed this off-list, and he understands my position now. My concern has to do with a _successful_ DELETE that isn't reflected in the collection listing. Ezra's approach is still acceptable, however.


I can already foresee one objection, as follows: after a DELETE, in order to
*know* how a collection has changed, you have to GET it again, which adds an
additional round-trip. On the other hand, the collection could have changed
anyway, so I'm not sure that the membership restriction obviates that extra
request.

It doesn't. Date queries minimize the damage, though. A cell-phone will typically get a chunked response, so small documents help.

Robert Sayre