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.
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: w3c-dist-auth-request <at> w3.org > [mailto:w3c-dist-auth-request <at> w3.org] On Behalf Of B. Shadgar > Sent: Tuesday, June 17, 2003 12:18 PM > To: WebDAV > Subject: WebDAV effeciancy(Continue reading)
Lisa Dusseault wrote: > 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 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(Continue reading)
> 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(Continue reading)
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(Continue reading)
RSS Feed