Re: FWD: Questions on the 02 versioning
Jeff McAffer OTT (Jeff_McAffer@oti.com)
Wed, 22 Sep 1999 17:07:10 -0400
From: Jeff_McAffer@oti.com (Jeff McAffer OTT)
To: jamsden@us.ibm.com (jamsden),
Message-ID: <1999Sep22.170000.1250.1328446@otismtp.ott.oti.com>
Date: Wed, 22 Sep 1999 17:07:10 -0400
Subject: RE: FWD: Questions on the 02 versioning
> -----Original Message-----
> From: jamsden [mailto:jamsden@us.ibm.com]
> Sent: Wednesday, September 22, 1999 4:23 PM
> To: ietf-dav-versioning
> Subject: RE: FWD: Questions on the 02 versioning
>
> <jm>Alternatively, MKRESOURCE "config" at / would put it in the server
> defined place and return the URL for where it put it. This is the
> "default". Users can spec a different Request-URI (other
> than /) if they
> are really keen. BTW, do we have any use-cases in which users really
> want their configs mixed with their domain resources?
>
> BTW, where do baselines go? These are effectively config
> constructed by
> the system when you do a deep CHECKIN. Presumably they have a URL as
> well?
>
> I'm very uneasy about all of this. Configurations really are
> metadata.
> They are not content or structure. They are configuration management
> info. If we start mixing metadata resources with domain resources, it
> significantly muddies the user view? There should be a "meta" area of
> the URL namespace where one can escape the domain and access configs,
> workspaces, activities, ... We can do better than the filesystem.
> </jm>
>
> <jra>
> I still think configurations are user-data. A user creates a
> configuration
> which
> represents a persistent set of revisions that taken together
> represent some
> solution to some problem. A different revision of that
> configuration selects a
> different set of member revisions which solve some functionally or
> non-functional enchancment to that problem. This is all user
> information, not
> system information, and so users should create and control them.
> </jra>
Metadata does not == system data. Users can define metadata (e.g.
properties are metadata). Following in that line, we don't see
properties stored as "related-resources" in the user's URL space. What I
am really saying is that if we start mixing metadata in with normal data,
it will become very hard for users to acutally use the system. I am NOT
saying that we force all metadata (e.g., configs) into a particular place
but rather that there is a default place and if you as a user want to
have your config somewhere else, you can spec that.
I will suggest again that we define an OPTION value which specs the
default location used by the server for creating this metadata. I don't
care what we call the option but its value should be a URL (e.g.,
http://foo.com/meta) and the spec should define at least part of the URL
space below this point (e.g. http://foo.com/meta/workspaces,
http://foo.com/meta/activities).
Jeff