Hi Alex! On 01/30/2008 03:57 PM Alexandru Stanoi wrote: > Tobias Schlitt wrote: >> On 01/30/2008 10:58 AM Derick Rethans wrote: >>> On Thu, 24 Jan 2008, Tobias Schlitt wrote:
>>>> After I duck some more into designing the "lock" feature for the >>>> Webdav component Kore and me discussed possible implementation >>>> scenarios yesterday and want to present our foundings to you here, >>>> to make a basic desicion for a design concept. I try to keep the >>>> necessary background information as short as possible, to not waste >>>> your time. There are basically 2 possibilities to implement locking: >>>> a) As a plugin for the (currently private) Plugin-API. >>>> b) Integrated into the transport and backend layer (SimpleBackend). >>> The first one, will also allow the locking to be used for other >>> backends, right? >> Correct, as long as those can/will implement a certain interface we >> need to design then, because there are adjustments in the backend >> needed to support such a plugin (e.g a global "lock the complete >> backend" command must be supported). >> Please note, that this implementation should work with other backends >> but might be even more imperformant than it will be for the filesystem >> based backend (e.g. for a database driven backend). > I imagine that a filesystem backend is more common than a database one. > But in any case, my opinion is that the lock functionality is better > implemented as a plugin. The plugin API looks like it was designed for > this kind of thing, with pre and post request hooks. This assumption is correct. The Plugin-API was designed for exactly this purpose. However, I changed my opinion in respect to the the more I dig into locking. It will actually mean to hook in front and after each of the requests currently supported by Webdav and will mean that we need to create several new request objects and to submit those to the backend for each of these hooks, which is quite a lot of overhead. Beside that, I don't see a database backend as that unrealistically, since eZ Publish content is stored in a database, AFAIK. In a database you have much more powerful options to check tree structures for cerain conditions (e.g. if there are locked nodes in the tree). We will loose this option if we implement lock as a plugin. > What other plugins are there? Are they able to use the lock plugin if > needed? Do they need the lock plugin loaded, or can they load it > automatically? There are no plugins at all, yet. This is also why the plugin API is private so far. Plugins are not intended to make use of each other and also not to load automatically. An idea for a plugin would be for example a WebdavLockTiein (to enable legacy locking) or a WebdavTemplateTiein (to allow users to submit custom HTML pages for error messages and stuff. I also had a WebdavAuthenticationTiein in mind. But all of these are just dreams so far. Regards, Toby -- Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer [EMAIL PROTECTED] | eZ Systems AS | ez.no -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
