Re: issue: Collection Document Fidelity

[Ezra Cooper <ezra@xxxxxxxxxxxx>]

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

It doesn't seem wise for a server to list resources at another server (call
them "foreign resources") as members to one of its collections. And I can
see the appeal in defining collection membership with the slash syntax,
since it makes DELETE straightforward to define. But if we spec it so that
folks know what to expect in the "normal" case (as above), then maybe we can
rely on pig-headed developers to stop being pig-headed--while on the other
hand if somebody has a brilliant use case for unrestricted membership, more
power to them. 

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. 

The 404 issue is more worrisome. Let's say resource X is a member of
collections C and D. I DELETE X, then fetch C and note that X was removed
(rightly). Later I fetch D and X hasn't been removed--even though X no
longer exists anywhere in the world. As a client, I'd like to notify D that
X should be dropped. Currently, I'd have no way to do this. The URL called X
doesn't exist and won't respond to a DELETE. This argues for "...the server
MUST remove the resource from any collections which it controls." It also
argues for not including in a collection any resources that you don't
control.

Thoughts?

Ezra