- From: Arthur van Hoff <avh@marimba.com>
- Date: Tue, 16 Sep 1997 12:00:16 -0700
- To: Judith Slein <slein@wrc.xerox.com>
- CC: w3c-dist-auth@w3.org, Push Workshop <www-push@w3.org>
- Message-ID: <341ED740.7C707179@marimba.com>
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
Received on Tuesday, 16 September 1997 15:04:48 UTC