RE: Enumerating repositories and worksp

From: Tim Ellison OTT (Tim_Ellison@oti.com)
Date: Wed, Feb 23 2000

  • Next message: Tim Ellison OTT: "RE: Labels"

    From: Tim_Ellison@oti.com (Tim Ellison OTT)
    To: jvasta@rational.com (Vasta, John)
    Cc: ietf-dav-versioning@w3.org (ietf-dav-versioning)
    Message-ID: <2000Feb23.143031.1250.1486289@otismtp.ott.oti.com>
    Date: Wed, 23 Feb 2000 14:32:17 -0500
    Subject: RE: Enumerating repositories and worksp
    
    
    I understand your point -- and I'd be interested to see what others say. 
     Jim A. has advocated out-of-band info for such things in the past.
    
    Tim
     ----------
    >From: Vasta, John
    >To: ietf-dav-versioning
    >Subject: RE: Enumerating repositories and worksp
    >Date: Wednesday, February 23, 2000 1:59PM
    >
    ><<File Attachment: HEADER.TXT>>
    >  <john>
    >     I think you can have it both ways, if there was
    >     a way to discover whether a server has constraints
    >     or not. The spec is almost there; we just need a way
    >     to discover whether the server has repositories, and
    >     where it insists workspaces be located. If there were
    >     two properties defined somewhere (e.g.
    >     DAV:repositories-root and DAV:workspaces-root), then
    >     if either of those properties are defined, a client uses
    >     their values to form URLs to repositories (and therefore
    >     activities, configurations, and versioned resources) or
    >     workspaces respectively. If a property is not defined,
    >     then clients are free to use any URL they please, for the
    >     corresponding type of resource.
    >  </john>
    >
    ><tim>
    >  If you were to follow this method, then I suspect that you would put
    >  DAV:workspaces-root on repositories too wouldn't you?
    ></tim>
    >
    >I think workspaces are independent of repositories, since they can select
    >any revision of any resource in any repository (at least, in the
    >implementation I am familiar with :^).
    >
    ><tim>
    >  Then the problem becomes finding repositories--and if I
    >  understand, you suggest that a list is available at a well-known
    >  location (e.g., any  resource, "/", etc.)
    ></tim>
    >
    >Right, except that I think there should be an independent list for
    >workspaces. And they aren't just "lists"; they are collection resources,
    >since a client will need to form URLs by appending a workspace or 
    repository
    >name to the collection URLs. Remember that this is needed not just to
    >discover what exists, but to create workspace or repository resources as
    >well.
    >
    >John
    >
    >