Re: Your proposal

Now we get into our areas of disagreement.

* I mentioned HTTP as having lousy performance WITHIN A SINGLE PROCESS.
 I guarantee you that a function call is much cheaper than formatting
the request into a stream, writing into a loopback socket, reading the
result back, parsing it,  and then the reverse.  Another example is
SQL access to properties of a resource.  If I want to query the resource
data efficiently, I need to be able to treat properties of the resource
as "virtual data", not make a series of function calls on each item in
the query set.  If I want to write a servlet that takes an HTML form
input and changes WebDAV properties, I definitely want a functional API
(in Java).  Everyone knows that SMB sucks and is incredibly chatty.  As
far as HTTP performance, it mostly depends on the amount of
functionality you can pack into one request.  If I have to issue a
GETLOCKED name request followed by a bunch of other requests to get all
of the state of a particular resource, HTTP will suck.

My point was that the WebDAV model is actually bigger than HTTP--other
data access systems (like SQL and XML technologies) should also be able
to manipulate the data easily.

* Another reason for making all information about a resource available
as properties is using XSL to format an HTML page giving access to all
of this data.  There is a lot of support for not requiring a lot of
programming (ala JSPs or ASPs) to format data within a page.

* I don't understand why you think it will be easier to handle protocol
extensions on the client side by using additional HTTP methods rather
than resources.  XML applications are used to ignoring elements that
they don't care about--extensibility is one of the key wins of XML vs.
traditional OO languages.  It allows DOM objects to be passed around
multiple areas of the system better.  For example, let's say that I have
some client library which implements the client side of the
HTTP protocol, and allows plugins to that client to access the
XML DOM for each resource.  I can install a new client plugin to handle
new properties that appear in that DOM, but I won't be able to extend
the HTTP protocol.  HTTP protocol implementation is typically at a lower
level of the client or server than properties.

HTTP request/response parsers are not generic technology like
XML parsers are

* It sounds like you are arguing against the general trend of making all
of your data available via XML, which is counter to the general
strategies most technology companies are following now, including
Microsoft and Oracle.  With your proposal, you are going to render all
of the burgeoning XML technology base useless, which is why the WebDAV
people built around XML in the first place.

Is anyone thinking about a thin-client WebDAV implementation (HTML only)
running in a browser?  I should be able to do stuff like changing RSRs,
manipulate directories, etc. with a web app.

--Eric

Yaron Goland wrote:

> I wouldn't accept a blanket statement that HTTP has lousy performance.
> I have seen it repeatedly beat the pants off all competing
> systems. For example, we did a speed comparison of a super optimized
> SMB implementation and DAV in W2K. DAV won hands down. The reason is
> that SMB, like most protocols of its ilk, is unbelievably chatty. They
> are basically RPCs rather than protocols. DAV, on the other hand, is
> extremely optimized. So even though the SMB implementation could
> process some ridiculous number of messages per second DAV still had
> better performance because it sent a hell of a lot less messages.As
> for the use of properties, I assert that there is no difference
> between executing a GETLOCKEDNAME method and getting the lockedname
> property in terms of how you write your back end. However, the first
> is a hell of a lot easier to deal with in terms of specifying and
> extending the protocol than the second. So the issue isn't one of back
> end implementation, it is one of front end convenience.In other words,
> just say NO to live properties.            Yaron
>
>      -----Original Message-----
>      From: Eric Sedlar [mailto:esedlar@us.oracle.com]
>      Sent: Monday, January 03, 2000 1:09 PM
>      To: Yaron Goland
>      Cc: w3c-dist-auth@w3.org
>      Subject: Re: Your proposal
>
>      One problem with your qualms about properties is that we are
>      trying to map WebDAV data to object representation systems
>      that do not have functional semantics, like XML.  We should
>      define an interface that doesn't rely on the distinction
>      between functional interfaces and properties for maximum
>      implementability on various servers.  (This distinction is
>      something may programmers have trouble with--does everyone
>      always bother to create accessor methods for everything?
>      ...)  The benefit of using live properties as a
>      representation is that object properties are more "portable"
>      to the other types of systems that may want to access the
>      same data, presumably through another means than the HTTP
>      protocol (which isn't particularly efficient).  (Which
>      brings me to another unrelated issue--should there be a
>      functional interface to WebDAV methods for programs living
>      in the same server as the data repository, given the
>      performance costs of HTTP within a single process--more on
>      that later). Yes you need a set of clear rules for how live
>      properties are used, and unless their use is rigorously
>      controlled, you will have compatability problems of the type
>      you cite, but this is a problem with any loosely written
>      standard.I think of properties in the JavaBeans sense--in an
>      OO language binding, they would actually be functional
>      interfaces to set and retrieve them, but could be overridden
>      to provide customized behaviour.  Any JavaBeans user has no
>      idea whether or not this piece of data is live or not, and
>      this model works well. --Eric
>
>           ----- Original Message -----
>           From: Yaron Goland
>           To: 'Eric Sedlar'
>           Sent: Monday, January 03, 2000 11:18 AM
>           Subject: Your proposal
>            Eric, I read your analysis of Geoff's proposal
>           and was really impressed by your deep grasp of
>           both HTTP and WebDAV.
>
>           I have a series of issues with your
>           counter-proposal but I'm going to hold off on
>           commenting until we can build up more of a common
>           base for conversation. Please see my post on the
>           mailing list in regards to this.
>
>           I did, however, want to point out a general design
>           issue regarding your proposal that isn't directly
>           related to locks. In your proposal you suggest
>           using properties to provide various bits of
>           protocol information, such as which names are
>           currently locked. I would caution against using
>           properties in this way, see
>           http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0302.html
>           for more details. For a history of how we ended up
>           in this mess in the first place see
>           http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0074.html
>           and
>           http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html.
>           BTW, all of these posts are collected in the
>           WebDAV Book of Why available at
>           http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0129.html.
>
>                           Thanks,
>                                           Yaron
>