On 11/7/05, Thomas Broyer <[EMAIL PROTECTED]> wrote:
>
> 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
>
>
>
