Author: kn
Date: Tue Aug 7 13:02:32 2007
New Revision: 5831
Log:
- Spelling and clarifications
Modified:
experimental/Webdav/design/design.txt
Modified: experimental/Webdav/design/design.txt
==============================================================================
--- experimental/Webdav/design/design.txt [iso-8859-1] (original)
+++ experimental/Webdav/design/design.txt [iso-8859-1] Tue Aug 7 13:02:32 2007
@@ -23,8 +23,7 @@
Because of the variaty of buggy and incomplete implementations of WebDAV, this
component will provide an abstraction to suite the different needs. Beside
-that, an abstract interface to the backend used for file operations will be
-provided.
+that, an abstract interface to the backend will be provided.
The main class of this component will provide a fully `RFC 2518`_ compliant
implementation of a WebDAV_ server. An instance of this class retrieves an
@@ -57,7 +56,7 @@
necessary capabilities to generate a response, it is called to do so. If the
server class can perform emulation of not available capabilities and rely on
different features of the backend. In case there is no way, the backend can
-handle, the request, the server class will indicate that with an error
+handle the request, the server class will indicate that with an error
response.
The way back flows through the 3 tiers back again: The backend handler
@@ -92,7 +91,7 @@
classes, which is only loaded by the main server object on-demand.
All configured transport handlers must implement the interface
-ezcWebdavTransportHandler, which defines the ncessary methods.
+ezcWebdavTransportHandler, which defines the necessary methods.
ezcWebdavBackendHandler
-----------------------
@@ -109,7 +108,7 @@
All other WebDAV operations are optional to be implemented by a backend handler
and are defined by the handler itself. It is an open issue, if the handlers
should implement different interfaces, to indicate different capabilities or if
-a bitmask or similar mechanisms are more efficient here.
+a bitmask is more efficient here.
The logical groups of capabilities are:
@@ -126,19 +125,20 @@
If the hander provides locking facilities on its own, the main server object
must not take care about that.
GZIP-Compress
- Handlers implementing this facility can deal with GZIP based compression.
-
+ Handlers implementing this facility can deal with GZIP and bzip2 based
+ compression.
If a handler does not support a certain facility and the main server object is
-not capable of emulating it with existing facilities, the server will respond
-using a "501" server error, "Not implemented".
+not capable of emulating it, the server will respond using a "501 Not
+Implemented" server error.
ezcWebdavTransportHandler
-------------------------
A class implementing this interface is capable of parsing a raw HTTP request
-into a struct extending ezcWebdavRequest. One transport handler is usually
-built to handle the communication with a certain set of specific client
+into a struct extending ezcWebdavRequest and generating the HTTP response out
+of the ezcWebdavResponse struct. One transport handler is usually built to
+handle the communication with a certain set of specific client
implementations.
A transport handler class will be able to parse the incoming HTTP request data
@@ -163,11 +163,11 @@
information - like URI, date and headers - the request object will contain
information about partial GET mechanisms to use and what else is important.
The backend handler will return an instance of ezcWebdavGetResponse if the
-request was handled correctly, or a corresponding error object, if the
-request failed.
+request was handled correctly, or a corresponding ezcWebdavErrorResponse
+object, if the request failed.
An open issue is, how the server instance can figure out best, which transport
-to use.
+to use - see below for this.
Example code
============
@@ -235,6 +235,9 @@
handler, which will result in messy code in the main server class, which needs
to check for several methods and interfaces, which could satisfy a request and
then choose the right method of the right interface to perform the work.
+Combination of partial *and* - for exampel - encoded request support would
+require to define a custom interface here which would end up in 2^$features
+interfaces and methods.
The second option is, to let the handler implement empty interfaces and just
let those be used for declarative purposes. That way, the above shown example
@@ -253,9 +256,9 @@
possibly add a parameter for partiality to the request struct.
The third alternative is to not use interfaces but a bitmask for handlers to
-indicate their capabilities. This will possibly the fastest and cleanest way,
-because one can define fine graned stages of capability support and can easily
-check on different capabilities.
+indicate their capabilities. This will possibly the fastest way, because one
+can define fine graned stages of capability support and can easily check on
+different capabilities.
Suitable transport
------------------
@@ -264,7 +267,7 @@
for a certain request. Currently, the main server instance will know about
available clients and will have a regular expression for each of them, to
identify the clients it communicates to. The regex must be defined by the user,
-while registering the handler.
+when registering the handler.
It is not clear, if 1 regex into 1 header field is enough to identify the
handler correctly every time. Therefore, it must be discussed, if handlers
--
svn-components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/svn-components
