W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2000

RE: Your proposal

From: Yaron Goland <yarong@Exchange.Microsoft.com>
Date: Mon, 3 Jan 2000 15:45:23 -0800
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619DEC@BEG.platinum.corp.microsoft.com>
To: "'Eric Sedlar'" <esedlar@us.oracle.com>
Cc: w3c-dist-auth@w3.org
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 <mailto:yarong@Exchange.Microsoft.com>  
To: 'Eric  <mailto:esedlar@us.oracle.com> 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
<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
<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
<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
<http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0129.html> .

                Thanks, 
                                Yaron 
Received on Monday, 3 January 2000 18:47:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:53 GMT