- From: Peter Raymond <Peter.Raymond@merant.com>
- Date: Thu, 11 Oct 2001 10:11:07 +0100
- To: Stefan Eissing <stefan.eissing@greenbytes.de>, "Clemm, Geoff" <gclemm@rational.com>, "DeltaV (E-mail)" <ietf-dav-versioning@w3.org>, ACL@webdav.org
- Message-ID: <20CF1CE11441D411919C0008C7C5A13B02AD3B61@stalmail.eu.merant.com>
Hi, Let me make sure I understand your "multiple server" scenario correctly: Imagine some parts of the namespace are being maintained by different servers the namespaces used to store version-histories, baselines, workspaces, activities, principals etc may differ. Consider the situation where I have a workspace hosted at: http://www.server1.merant.com/dav/project1 and in that workspace we have a collection which has a binding to a resource on some other server), eg: http://www.server1.merant.com/dav/project1/src has a member which is a binding to http://www.server2.merant.com/dav/project2/src/main.c If my client connects to server1 and does a OPTIONS on /dav and gets back the DAV:version-history-set they might get: http://www.server1.merant.com/dav/vhr If the client did a PROPFIND on http://www.server2.merant.com/dav/project2/src/main.c for it's DAV:version-history property it might return: http://www.server2.merant.com/dav/vhr It seems to make sense that the version histories for resources live on the same server as those resources. Which implies that if you have "cross-server" bindings then different collection sets apply to different parts of the namespace. So I guess I support option number 2. I also like the idea of all the specifications being consistent. Regards, -- Peter Raymond - MERANT Principal Architect (PVCS) Tel: +44 (0)1727 813362 Fax: +44 (0)1727 869804 mailto:Peter.Raymond@merant.com WWW: http://www.merant.com -----Original Message----- From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] Sent: 11 October 2001 09:38 To: Clemm, Geoff; DeltaV (E-mail); ACL@webdav.org Subject: RE: [ACL] principal-collection-set > From: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On Behalf Of > Clemm, Geoff > > Just to make sure we're on the same page, the interaction between > the client and a server will not be to ask each resource "where is > your xxx-collection-set", but rather to ask the first encountered > resource in a session "where are the xxx-collection-set values on > your server", and then use those values for the rest of the session. Yes, that's what I'm concerned about. Without going too much into detail, I have a server with an internal plugin-structure and all "server" protocol values (xxx-set, DAV header, methods) can and will vary. For now, they can vary with each collection. If we have BINDINGs in the future, it may vary with each resource. So, getting those values "once for the session" is wrong and clients following that advice are broken. //Stefan > This means that you would not be combining requests for xxx-collection-set > information with the other property information, but rather will be > asking for xxx-collection-set information around the same time you > are asking for OPTIONS information (i.e. what options are supported > by your server), which is why the xxx-collection-set information is > currently marshalled via OPTIONS, since *that* allows you to get all > this "configuration" information in one request. > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > 1) Keep DeltaV with OPTIONS, and make ACL use OPTIONS for consistency > > 2) Change DeltaV to use properties, and have ACL use properties > > 3) Have DeltaV and ACL use different ways to obtain xxx-collection-set > > > > The main situation I *really* want to avoid is: > > 4) Change DeltaV to use properties, and have ACL end up using OPTIONS > > or some other non-property mechanism inconsistent with DeltaV. > > > > So for those folks that care about this (probably not many :-), > > which choice do you prefer? > > Obviously, it MUST be consistent across deltaV, ACL and future WebDAV > versions. > > I honestly think that 2) is the best solution. For instance, it allows a > client to collect all it needs to know about a resource with one request. > _______________________________________________ > acl mailing list > acl@webdav.org > http://mailman.webdav.org/mailman/listinfo/acl >
Received on Thursday, 11 October 2001 05:13:05 UTC