Eric Scheid wrote:
On 6/11/05 10:12 AM, "Luke Arno" <[EMAIL PROTECTED]> wrote:
What exactly is a collection and what does it do?
I want to know this too.
Originally, I thought they was analogous to directories in a filing system.
The spec even said something like that. They were buckets into which an
entry could be stored. If entries were tangible things, and they were
scattered all over the floor, you could imagine scooping them up into
collections. Nice and tidy.
Now, I see people talking about them as if they are instead {magic sets},
complete with possibilities of overlapping and sub-setting, and entries are
not actually stored in a collection per se, they are simply members
referenced in any given collection. Entries exist, as entries, someplace
else, but that place is not specified, and though a new entry can be created
there by posting to a collection, that same entry can't be deleted via that
same path. No pace exists for deleting actual entries which presupposes the
collections are sets model.
The picture is not clear.
I can see two point of views / models. We definitely need to choose one
or the other and make that clear for everyone. Maybe the Chairs could
call for consensus.
1. Collections are containers for Entries
You create an entry by POSTing to the Collection URI.
When you POST the same Entry to another Collection, a new URI is
assigned (TBD: might theses two URIs point to the same resource or
should it be a copy? corollary: when you PUT on an URI, and GET on the
other one, are the changes reflected?)
When an entry is DELETEd, this shows up immediately in the Collection
membership listing (mark as deleted, or don't show anymore; this is
another question, related to syncing). If an Entry has two URIs, only
the Collection that created that URI on the HTTP POST is updated, as the
Entry still exists /via/ the other(s) URI(s) belonging to other Collections.
This is a similar approach than having Collections as directories [1]
and Entries as hard links [2].
2. Collections are containers for URIs or Entries
When you POST an Entry to the Collection URI, this has actually two
effects: create the Entry resource and assign it an URI _and_ add that
URI to the Collection.
When you POST the same Entry to another Collection, the server can reuse
the same URI (after having searched for the atom:id in its whole entry
store) or it makes a copy (and assigns a new URI; when PUTting on an URI
and GETting at the other one, changes are _not_ reflected).
When an Entry is DELETEd, Collections referring to it _might_ not be
updated and still list the Entry (broken link)
This is a similar approach than having Collections as directories [1]
and Entries as symlinks [3] (with potential broken links).
[1] http://en.wikipedia.org/wiki/Directory
[2] http://en.wikipedia.org/wiki/Hard_link
[3] http://en.wikipedia.org/wiki/Symlink
--
Thomas Broyer
