Subject: WebDAV effeciancy

From: "B. Shadgar" <[email-masked]>
Date: Tue, 17 Jun 2003 20:17:36 +0100

Hi all,

I am wondering if somebody can reference me a practical statistic of
comparing the HTTP functionality to the WebDAV functionality with regard
to remote Web authoring. I'm especially interested about the rate of
speed, security, and flexibility. Any thing more is most welcome.

Thanks in advance for your help.

Regards,
Bita.

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 17 Jun 2003 12:29:31 -0700

Bita,

What do you mean by comparing the HTTP functionality to the WebDAV
functionality?  WebDAV extends HTTP in order to do proper authoring, so
there is no real functionality comparison based on authoring.  HTTP doesn't
do the authoring functions that WebDAV adds, that's why WebDAV had to add
these fucntions.

Since WebDAV extends HTTP:
 - they both have exactly the same theoretical speed/flexibility
capabilities for downloading documents and uploading documents (these are
the most common HTTP actions that are also common WebDAV actions)
 - they have exactly the same security features

One could imagine doing performance comparisons between WebDAV functionality
and, for example, the Microsoft FrontPage extensions which do many of the
same functions.  Or one could compare a WebDAV authoring site to a site
using HTML forms for authoring (like Yahoo PageWizards).

Perhaps I've misunderstood your question.

Lisa

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of B. Shadgar
> Sent: Tuesday, June 17, 2003 12:18 PM
> To: WebDAV
> Subject: WebDAV effeciancy
> 
> 
> 
> Hi all,
> 
> I am wondering if somebody can reference me a practical 
> statistic of comparing the HTTP functionality to the WebDAV 
> functionality with regard to remote Web authoring. I'm 
> especially interested about the rate of speed, security, and 
> flexibility. Any thing more is most welcome.
>

---

From: "B. Shadgar" <[email-masked]>
Date: Tue, 17 Jun 2003 21:14:54 +0100

> Perhaps I've misunderstood your question.

Lisa,

I haven't expressed my question correctly - sorry. By WebDAV and HTTP, in fact
I meant comparing the process of communication between the WebDAV servers and
clients compare to the HTTP ones.

I agree with you that WebDAV is an extension on HTTP and provide all
functionality of the HTTP, added some new functionality regarding the metadata,
access control, locking and so on. However, since there is more processing for
those new functionality in environment based on the WebDAV protocol, I am
wondering how much this would effect on the speed. Also many functionality of
the WebDAV can be implemented by HTTP POST method, Soap and so on ( as you
mentioned like Microsoft FrontPage). So if the security is the same and if the
speed may be low (not sure), why would the user choose WebDAV rather HTTP?

Thanks,
Bita.

---

From: Elias Sinderson <[email-masked]>
Date: Tue, 17 Jun 2003 14:06:03 -0700

B. Shadgar wrote:

>[...] many functionality of the WebDAV can be implemented by HTTP POST method, Soap and so on ( as you
>mentioned like Microsoft FrontPage). So if the security is the same and if the speed may be low (not sure), why would the user choose WebDAV rather HTTP?
>
I'm actually implementing a SOAP-WebDAV proxy service that provides 
WebDAV functionality to clients that do not speak WebDAV, yet have a 
HTTP stack and can do XML processing (and, hence, SOAP as well). I'll be 
running some performance tests and can send them to you when they're 
available if you're still interested. Ignoring the performance issue 
momentarily, however, there are several reasons one should use WebDAV 
over HTTP POST, SOAP, and cetera. Without digressing into a full 
discussion of architectural styles and ideals not appropriate for this 
forum, I'll summarize what I feel is the main consideration.

One of the reasons that the web has been so successful is that, at the 
protocol level, there is a standardized interface for interacting with 
web resources. WebDAV has extended the HTTP protocol to provide 
functionality necessary for distributed and collaborative authoring. 
SOAP breaks this genericity of interface by allowing arbitrary methods 
with arbitrary functionality to be exposed as a web service. So, while 
it is possible to provide WebDAV-like functionality using SOAP, there is 
no guarantee of interoperability between clients and servers taking this 
approach. Another, somewhat lesser, concern has to do with the opacity 
of URLs. A SOAP based web service that provides WebDAV functionality is 
essentially manipulating web resources indirectly; behind the scenes, as 
it were, so the resource you would address a PROPPATCH to isn't the same 
resource that you would address a GET to, even though you are intending 
them to be the same...

Regarding performance, I have stong suspicions that straight WebDAV 
would be faster than any SOAP-based service due to the overhead in 
marshalling/demarshalling the request and response bodies. Again, I'll 
be testing this empirically in the next couple of months. That being 
said, there are compelling reasons why such a service might be 
desirable. As I mentioned above, some classes of devices don't support 
WebDAV, but can do SOAP over HTTP and it may be desireable to provide 
WebDAV functionality to these devices until their protocol stack is 
enhanced. Further, it allows one to insert extra processing (such as 
transactional support, for example) into the mix. This home grown 
solution is somewhat half-baked though, since it only allows for the 
client to interoperate with a single server/service implementation.

Hope this has shed a little light on your questions...

Cheers,
Elias

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 17 Jun 2003 16:34:32 -0700

> I haven't expressed my question correctly - sorry. By WebDAV 
> and HTTP, in fact I meant comparing the process of 
> communication between the WebDAV servers and clients compare 
> to the HTTP ones.
> 
> I agree with you that WebDAV is an extension on HTTP and 
> provide all functionality of the HTTP, added some new 
> functionality regarding the metadata, access control, locking 
> and so on. However, since there is more processing for those 
> new functionality in environment based on the WebDAV 
> protocol, I am wondering how much this would effect on the 
> speed. Also many functionality of the WebDAV can be 
> implemented by HTTP POST method, Soap and so on ( as you 
> mentioned like Microsoft FrontPage). So if the security is 
> the same and if the speed may be low (not sure), why would 
> the user choose WebDAV rather HTTP?
> 

A WebDAV server can be implemented that has the same performance as an HTTP
server, for the HTTP functions.  THat is to say, as long as the server is
being used only for HTTP functions, it would have the same performance and
scalability.  A thousand GET requests can theoretically be handled in the
same time whether or not you've got WebDAV.

When the server's usage includes WebDAV requests as well, obviously this can
change things -- and now it really depends on the scenario.
 - When users start using WebDAV functionality, are they doing *more*
requests?  On top of the thousand GET requests per minute, are users now
also doing a thousand PROPFIND requests?  Obviously this is twice as many
requests and takes more processing time on the server.
 - On the other hand, when users start using WebDAV does this *replace* HTTP
requests?  Imagine 500 of our 1000 GET requests are directory listings, so
when WebDAV replaces the server generated directory listings, there are then
500 GET requests and 500 PROPFIND requests in an average period.  Now the
server can be *faster* because it should be faster to generate and send 500
PROPFIND responses than to compile 500 dynamically-generated GET responses
with the same directory listings.  That's because in the HTTP scenario the
server is responsible for generating the presentation (in HTML) of the info,
whereas in WebDAV the client is responsible for presentation.

This kind of analysis can be extended.  In general, and on average, I think
we find that when the server has to do presentation it has more work to do,
and thus has worse performance and worse scalability.  WebDAV generally
allows the server to do less presentation work, which should improve its
performance and scalability (as long as the overall usage patterns do not
change, which they might).

An example of this was documented at Microsoft in the development of Outlook
Web Access for Exchange 2000.  When the server had to do all the
presentation work itself, the OWA server could not handle so many users.
When the server offloaded the presentation work using scripting, stylesheets
and WebDAV, the number of users that could be handled increased by a very
significant amount. If the client supported WebDAV without needing scripting
and stylesheets (if it had all its own presentation logic) then even more
clients could have been handled.

So in a general authoring scenario, I would expect WebDAV to be much more
scalable and high-performing than a HTTP interface that uses forms (like
Yahoo PageWizards).

Now let's consider FrontPage.  FrontPage is very much like WebDAV in the
semantic operations it defines.  Thus, we would expect its performance to be
very much like WebDAV.  They both extend HTTP, it's just that FrontPage does
it in different ways.  But both FrontPage and WebDAV leave the presetnation
layer to the client so they have similar characteristics.

SOAP is an entirely theoretical case.  There doesn't exist a set of
authoring operations defined for SOAP.  So how could we compare them?  SOAP
is a protocol for delivering XML payload but it doesn't define any schemas
for payloads that would allow authoring operations, like LOCK and UNLOCK and
metadata operations.  If you were to write a new schema for SOAP to define
authoring operations, since SOAP is based on HTTP as well it might be as
scalable as WebDAV, but it would likely be less scalable (because there is
overhead in SOAP that WebDAV doesn't seem to need).

There are a number of factors you didn't mention, beyond
performance/scalability, why a user would choose WebDAV authoring rather
than a non-standard HTTP-based client authoring solution.
 - WebDAV allows clients to syncrhonize data in order to maintain sites
(sitecopy), for offline usage or to run automated backups (Xythos WFC).
 - WebDAV allows clients to control the UI.  Your UI can be 
	Command-line (like cadaver)
	Mac-like (WebDAV-FS, Goliath)
	Windows Explorer (Xythos WFC, Web Folders)
	A search-oriented file "locator" rather than explorer (KCura)
 - WebDAV allows users to save straight from Office and Adobe authoring
applications (and any other app that chooses to support WebDAV).  This saves
the upload step.
 - WebDAV allows the user/client to choose a language and supports
sight/hearing disabled usage better than HTML.
 - WebDAV allows locks to be obtained automatically by the authoring
application.  HTTP-based authoring sites either don't support locking or
make the user get locks manually (like www.sharemation.com)

Beyond this I suggest you preorder my book, though it's not out quite yet.
(http://www.amazon.com/exec/obidos/tg/detail/-/0130652083/qid=1055892821/sr=
1-1/ref=sr_1_1/103-3410589-6207009?v=glance&s=books)

Lisa