Re: High-level capabilities
David G. Durand (dgd@cs.bu.edu)
Thu, 6 Jun 1996 22:53:47 -0400
At 11:57 AM 6/6/96, Jim Whitehead wrote:
After I commented on Jim's points one-by-one, I realized that more than
half my comments are based on the premise that whatever we define should
support but <em>not</em> define policies.
I'm also assuming that the <em>minimal</em> requirements should be the
simplest possible features needed for version support -- so for instance,
most configuration management is not minimal, though it is important. I
think top priority should go to straigh version management, to get
something into place pronto -- we can add configurations later, and that
seems best to me. I support compelting the minimal requirements, and then
going back to fill in the rest.
>Browsing support capabilities:
>
>1. Retrieval of a stated version of an entity: Any given revision of an
>entity should be accessible, thus supporting links to stated revisions of
>entities. (This capability is provided by the ";version={opaque version
>id}" capability we have been discussing.)
Check!
>2. Browsing within a collection of entities: Often multiple entities
>together form a logical grouping, for example, a collection of HTML and GIF
>entities which comprise online documentation for a software product. It is
>desirable to provide support for browsing within such a collection without
>requiring either the user or the entities to explicitly name the
>destination entity version of each link traversal.
The minimal requirement is less than than the general form of this. If the
server can return the "current" version for an entity when an version-free
URL is supplied by that entity, then the user will be browsing within the
"current version space". The server is free to ensure that this is a
consistent configuration.
If you want to accomodate an arbitrary set of configurations, you need a
versioning-aware browser, so at that point you can be using more-advanced
software to access more abstract configuration operations. Supporting an
arbitrary number of configurations is an important requirement, but not a
minimal one.
>3. Retrieval of derivation relationships between versions of an entity: The
>ability to trace the development and ownership of an entity provides
>visibility into the development of that entity, and into the namespace of
>version identifiers for versions of that entity.
I agree that tracing ancestry relationships is useful. I'm not sure what
kind of insight you can gain into the "namespace" of <em>opaque</em>
version identifiers. You should be able to gain information about the
relationships of specific instantiated items in the namespace, but more
insight than that breaks the opaqueness of the version-id.
>4. Writing to a given version of an entity: Once changes have been made to
>an entity, versioning policies often dictate that the changes be written
>into a new, stated version of that entity.
Yes, but doesn't the server just notify you of the version you get? Perhaps
you should be able to request a particular version number, so that the
server can accomodate you if it is willing and able. Presumably you she be
required to specify the version being updated (or none, to update the
current version, if the server allows it). You then get back the new URL,
or a reason why it was not done.
I think that this is mainly a server issue, not a protocol one.
>5. Policy-neutral versioning: the methods defined for accessing, modifing,
>and locking entities should allow multiple versioning policies to be built
>on top of them. For example, lock-based policies, as employed by RCS, and
>merge-based policies, as implemented in CVS, should both be implementable.
>Since a wide range of applications will use versioning, the greater the
>flexibility in the types of versioning policies which may be supported, the
>greater the types of applications that can employ this protocol.
Hear, hear.
>6. Parallel development support: Since it frequently occurs that multiple
>people edit the same entity simultaneously, this type of activity must be
>supported. User agents must be supplied with enough information to inform
>their users when they are entering a parallel development situation, and
>they must be supplied with the versions of parallel entities so they can
>provide merge support for the entity contents. Futhermore, since it is
>currently beyond the state of the art to provide merge support for certain
>entity types (e.g., MPEG video), it must be possible to disallow parallel
>development on these entity types.
Server issue. I don't think this affects the protocol at all.
>7. Visibility control: Through the user agent, it should be possible to
>control the external visibility of an entity. For example, this is useful
>for ensuring that working revisions of an entity are not accessible by the
>entire world.
This sounds like a non-minimal requirement to me, because it is another
policy issue Some servers might control this automatically, or require
manual intervention via some separet communication channel. Do we perhaps
need a general protocol for negotiating server policy options? Then we'd
have a way to standardize setting of such options, but leave the door open
to the wide variety of different policies.
>8. Configuration support: The user must be able to create versioned
>collections of versioned entities. When creating online documentation, an
>author will create multiple pages, which may, for example, contain an HTML
>document and supporting bitmap graphics and applet objects. The author
>will want to make a versionable collection of the entities which comprise
>each page, as well as a versionable collection of all the pages.
This seems like the update portion of requirement 2. Seems like a
non-minimal issue to me (except possibly again in dealing with the "current
version").
>Note that you might not want all users to be able to employ all
>capabilities all the time. For the development of these requirements, I
>have assumed a super-user who would be able to do everything, all the time.
>Access control mechanisms can limit which users can employ which
>capabilities.
We seem to be at policy again. I had been assuming that HTTP authorization
mechanisms would provide sufficient security so that a server could
implement whatever policy it wants.
>- Jim Whitehead <ejw@ics.uci.edu>
----------------------------------------------+----------------------------
David Durand dgd@cs.bu.edu | david@dynamicDiagrams.com
Boston University Computer Science | Dynamic Diagrams
http://cs-www.bu.edu:80/students/grads/dgd/ | http://dynamicDiagrams.com/