Re: factoring of DAV services

> By stoping at the "resource" boundry and also by not separating the
> services offered by a DAV system we are not scaling the DAV system itself.
> Here are some examples. 

Since we're talking at the abstract layer, it's easy to generate
misunderstanding.
A "resource" is in fact a service; an object, if you will.

(I'd disagree with the post that we're not adopting an "object-oriented"
framework; I think the 'web' is object-oriented in that resources are
the objects, URLs are object pointers, although web resources normally
only offer methods of GET, PUT and POST, although we're considering
additional resource-based methods; insofar as we add additional methods,
it ties the delivery of services to those transports that offer
additional methods.)

We've noted, for example, that the resource of "the source" is a
different resource from "the generated content", with a link
relationship of derived-from. So you can 'get the source' by applying
the GET method to the source instead of applying it to the derived
content, e.g., for web pages with server-side includes. However, with
this choice, we're also allowing the source and the generated content to
be on separate machines.

Scalability and distribution are good properties in the abstract, but in
practice, it's possible to carry the abstract goal farther than
necessary, while at the same time, burdening the implementations with
too many levels of indirection. So we need to carefully balance the
separation of objects against actual practical needs.

The main "scalable" case I'd like to argue for, for DAV (and perhaps
this is a request to add something to the requirements document) is that
it should be possible to do authoring against a completely separate
machine than the machine(s) that are actually serving the content being
authored. 

I'm imagining for security & firewall considerations, as well as for
load distribution, that one might want to have a separate server which
handles all authenticated operations of update, but that, as far as the
user and client are concerned, they *start* with the web server. That
is, if you have "davserver.host.dom" and "www.host.dom", you might find
that the URLs for the version tree, the source of documents, etc., are
all "http://davserver.host.dom", even though the documents that you're
actually authoring are "www.host.dom". It should be possible to not have
to authenticate against the machine that is actually serving the
documents.

> This is why I wondered if a service model had been developed.

Your scenarios are interesting; the question is whether a standard
should dictate a service model, or just allow a wide variety of service
models. Although any product architecture needs a service model, we're
clearly trying to support "all of them". Perhaps we should instead try
to focus on just documenting the service models of the products that
we're trying to support.

Larry
--
http://www.parc.xerox.com/masinter

Received on Tuesday, 6 May 1997 12:26:29 UTC