Author: kn
Date: Tue Aug 28 10:38:15 2007
New Revision: 5956
Log:
- Resolved open issues from discussion
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 28 10:38:15 2007
@@ -113,9 +113,12 @@
- propFetch()
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 is more efficient here.
+and are defined by the handler itself. The additional basic capabilities of
+backend handlers are indicated by implementing interfaces for the support
+additional request methods, like put, change, etc.
+
+Additional features, like encryption support will be indicated by returning a
+bitmask of supported features by the backend handler.
The logical groups of capabilities are:
@@ -173,8 +176,10 @@
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 - see below for this.
+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 by matching the regualr expression against the client name provided in the
+HTTP headers.
Example code
============
@@ -191,7 +196,10 @@
// Server data using file backend with data in "path/"
$server->backend = new ezcWebdavBackendFile( '/path' );
- // Register transport handlers
+ // Optionally register aditional transport handlers
+ //
+ // This step is only required, when a user wants to provide own
+ // implementations for special clients.
$server->registerTransportHandler(
// Regular expression to match client name
'(Microsoft.*Webdav\s+XP)i',
@@ -208,80 +216,6 @@
// Serve requests
$server->handle();
-Open issues
-===========
-
-There are several open issues which need to be discussed before starting to
-implement this design:
-
-Capabilities
-------------
-
-Backend handlers can offer several different capabilities as noted in the
-specific section. It is not set, if the indication of supported capabilities
-should be done by implementing interfaces or going another way.
-
-Implementing interfaces would be a nice, OO-style solution, but can possibly
-end up in a huge lot of interfaces and possibly with interfaces that don't
-indicate any methods. For example, every handler needs to support GET and can
-optioanlly support partial GET. There are several ways, how a handler can
-indicate that he supports this:
-
-The implementation of an interface is the most plausible one: ::
-
- <?php
-
- interface ezcWebdavPartialGetHandler
- {
- public function partialGet();
- }
-
- ?>
-
-Going this way, we end up with 1 method for every special case for a
-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
-would implement ::
-
- <?php
-
- interface ezcWebdavPartialGetHandler
- {
- }
-
- ?>
-
-The server class could then use the interface to determine the capability of
-partial GET and utilize the usual get() method to initialize the operation and
-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 way, because one
-can define fine graned stages of capability support and can easily check on
-different capabilities.
-
-Suitable transport
-------------------
-
-Another open issue is the mechanism to identify a suitable transport handler
-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,
-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
-shouldn't better have a static method like canParse() to perform the parsing
-checks on their own. That way, the mechanism to identify the correct handler is
-much more flexible, but all classes need to be loaded on every request.
-
..
Local Variables:
--
svn-components mailing list
[EMAIL PROTECTED]
http://lists.ez.no/mailman/listinfo/svn-components
