- From: Eric Sedlar <esedlar@us.oracle.com>
- Date: Mon, 03 Jan 2000 16:33:15 -0800
- To: Yaron Goland <yarong@Exchange.Microsoft.com>
- CC: w3c-dist-auth@w3.org
- Message-ID: <38713FCB.ED63D67C@us.oracle.com>
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 >
Received on Monday, 3 January 2000 19:26:06 UTC