Re: Collections

Hi Judith,

The aim of a DRP index is slightly different than
collections. We tried to address the following issues:

- A DRP index is defined to make the subsequent transport
  of files more efficient by providing unique identifiers
  (content identifiers) for each file in the index.

- Provide a single transactional "snapshot" of a set of
  data objects (entities) which are entirely consistent
  with each other. It is important that this can be done
  in a single request, because multiple requests would
  require locking which may result in additional overhead.
  This is an extremely important feature, in particular
  when used for software distribution.

- A DRP index can be generated by a server on the fly,
  but it can also be stored in an ordinary file. This is
  useful because it allows the use of indexes in servers
  that don't directly support DRP.

- A DRP index can be obtained using a normal HTTP request.
  This is important because the DRP must be deployable today
  in order to be interesting. We considered definining a new
  HTTP method, but that would pose serious deployment issues
  when using existing HTTP servers and proxies.

- A DRP index contains file sizes so that the client can 
  determine the total download size when doing an update
  ahead of time.

- Files in an index are not required to have a content
  identifier. The content identifier can be omitted for
  dynamically generated files.

By the way, I would love to get a pointer to the latest
definition of a web-dav collection. I haven't been able
to find it yet.

Judith Slein wrote:
> 
> If there was a discussion period on collections, I missed it.  I do
> have some comments to make, however, especially in light of DRP.
> 
> The DRP index differs from ours (aside from implementation details) in
> several ways:
> 
> 1. It describes the entire hierarchy, whereas ours describes only a
> single level of the hierarchy.

That was done to make it easier to fetch the state of an entire
channel or application without requiring multiple requests.

> 2. It contains different information about each member of the
> hierarchy.

It would be acceptable if a web-dav collections would be a super set
of a DRP index. However, for efficiency it may be necessary to request
certain "views" on a collection. A DRP client may request on a subset
of all the information which is needed for transport.

> 3. DRP hierarchies have only internal members, whereas WEBDAV allows
> both internal and external members.

I'd like to learn more about this. We tried to add some notion of
external members, but we found that the index format got too complex.

> To reconcile the two specifications, I think (1) it would be very useful for 
> us to provide an index that describes the entire hierarchy rather than
> just one level.

Yes.

> I think what is really desirable for (2) is for the client to be able to
> specify in an INDEX request what information it wants about the members of
> the collection.  Collections are used for lots of different purposes, and
> different properties of the members will be useful in different contexts.

Right. That would be ideal.

> However, this flexibility would make it impossible for the index to be
> stored as a file, as DRP suggests -- it would have to be generated in
> response to the client's request.

I'm not sure why that is so. Couldn't you generate a file containing
a DRP flavored collection? I would really like to stay away from
defining
new HTTP methods if at all possible.

> As for (3), I think that allowing external members of collections is
> essential.  This is what allows the same resource to be shared by several
> collections.

I agree. I'd like to see how the web-dav specification deals with this.

Have fun,

	Arthur van Hoff