Author: kn
Date: Tue Jul 31 14:42:07 2007
New Revision: 5775
Log:
- Update on design doc
# Please go ahead - nothing here: Just added some ideas for internal
# discussions.
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 Jul 31 14:42:07 2007
@@ -40,6 +40,128 @@
clients. A factory pattern implementation will be provided, which takes
automatically care of creating the correct server instance for a client.
+Backends
+--------
+
+Lock checking for all operations is done centrally in the server, which may
+dispatch to the backend - see below for details. There are several groups of
+methods which a backend should implement for full functionality:
+
+- Options
+
+ Mandatory to implement?
+
+- Properties (propfind, propfetch)
+
+ Mandatory to implement?
+
+- Make collection (mkcol)
+
+ Mandatory to implement?
+
+- Writing (put)
+
+ Mandatory to implement?
+
+ There are several optional methods which or may not be supported by the
+ backend, like md5 checksum verfication, partial puts and content encoding.
+ Do we want to provide interfaces for all of them, or just let the backend
+ send "501 - Not implemented"?
+
+- Changing (delete, copy, move)
+
+ Mandatory to implement?
+
+- Get, Head
+
+ GET seems to require support for partial data. Should this be done in the
+ server? Multipart responses should be aggregated and served centrally by the
+ server only with requests for contained files to the backend?
+
+- Lock, Unlock
+
+ Optionally done in the server with dead properties in the client, or
+ dispatched to the client, if it implements ezcWebdavBackendCustomLocking
+
+Classes
+=======
+
+Request processing
+------------------
+
+ezcWebdavServer
+
+ Implements a method handle() which is called to process a request by a
+ client. Basing on the client name optionally dispatches to specialized
+ request reader / writer.
+
+ezcWebdavRequestReader
+
+ Standard conform class for parsing and interpreting requests to the
webdav
+ server. Specialized extensions of this class may be registered in the
main
+ handler for misbehaving clients.
+
+ezcWebdavRequestWriter
+
+ Standard conform class for responding requests to the webdav server.
+ Specialized extensions of this class may be registered in the main
handler
+ for misbehaving clients.
+
+Backends
+--------
+
+ezcWebdavBackend
+
+ Abstract base class for all webdav backends.
+
+ezcWebdavBackendFile
+
+ Implementation of a webdav backend serving the contents of a directory
+ tree.
+
+ezcWebdavBackendCustomLocking
+
+ Interface implemented by backends which hanlde the locking itself.
+
+Example code
+============
+
+::
+
+ <?php
+
+ $server = new ezcWebdavServer();
+
+ // Server data using file backend with data in "path/"
+ $server->backend = new ezcWebdavBackendFile( '/path' );
+
+ // Register custom reader implementation to extend the list of already
+ // used special implementations
+ $server->registerReader(
+ // Regular expression to match client name
+ '(Microsoft.*Webdav\s+XP)i',
+ // Class name of reader, extending ezcWebdavRequestReader
+ 'customWebdavMicrosoftRequestReader'
+ );
+
+ // Serve request
+ $server->handle();
+
+Algorithms
+==========
+
+Algorithms to select proper reader and writers for parsing and serving a
+request.
+
+Select reader / writer
+----------------------
+
+The standard webdav server contains a list of readers and writers associated
+with regular expressions which should match the client name to be used. As a
+fallback the stadards complient reader / writer will be used.
+
+Special implementation added by the user will be add on top of the list, to be
+used at highest priority.
..
--
svn-components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/svn-components
