Re: issue: Collection Document Fidelity

[Joe Gregorio <joe.gregorio@xxxxxxxxx>]

On Thu, 17 Mar 2005 11:24:19 -0800, Ezra Cooper <ezra@xxxxxxxxxxxx> wrote:
> 
> > From: Robert Sayre <mint@xxxxxxxxxxxxxxx>
> > Date: Wed, 16 Mar 2005 22:28:41 -0500
> > To: Atom Protocol <atom-protocol@xxxxxxx>
> > Subject: issue: Collection Document Fidelity
> >
> >
> > If my collection document lists a resource on another server as a
> > member, MUST it track the state of that resource? If you send a DELETE
> > to the other server, MUST the collection document remove it from its
> > representation? Since PaceSliceAndDice3 allows a totally hip basically
> > freeform version of collection membership, MUST all collections remove
> > the document from its representation?
> 
> 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.

Does that mean that the un-Deletable resources should not be listed 
in the collection? That they should be flagged in the Collection Document
as un-deletable, or do we rely on a 403 Forbidden when the DELETE
fails?

Personally, I prefer relying on 403 Forbidden. 

In the case where the DELETE succeeds, I do believe your wording should
be fine, with the addition of 'successful':

  "In response to a successful DELETE, the server
   SHOULD remove the resource from any collections 
   which it controls."

 
> 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.

Agreed. You have no idea what has happened to a collection, even 1/10th
of a second after you do a GET on a Collection Resource. That would
be an artifact of the 'statelessness' of HTTP.

   -joe

-- 
Joe Gregorio        http://bitworking.org