RE: [ACL] principal-collection-set

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
>