You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Brian Moseley (JIRA)" <ji...@apache.org> on 2005/10/11 17:02:26 UTC

[jira] Commented: (JCR-249) Webdav: Review usage of command chains

    [ http://issues.apache.org/jira/browse/JCR-249?page=comments#action_12331804 ] 

Brian Moseley commented on JCR-249:
-----------------------------------

the import/export handlers should also have access to the resource that is being imported or exported itself, not just the backing node. this gives greater flexibility for DavResource implementations to provide additional collaborating objects to the handlers.

> Webdav: Review usage of command chains
> --------------------------------------
>
>          Key: JCR-249
>          URL: http://issues.apache.org/jira/browse/JCR-249
>      Project: Jackrabbit
>         Type: Improvement
>     Reporter: angela
>     Assignee: angela

>
> i'd like to review the usage of command chains for import/export within the simple webdav server.
> while the concept of command chains offers a lot of flexibility, it showed that the implementation generates some drawbacks. a new mechanism should take advantage of the experiences made with the command chains.
> from my point of view the following issues should be taken into consideration:
> - provide means to extend and modify the import/export logic with minimal effort
> - consistent import/export functionality for both collections and non-collections
>   > export/import should not be completely separated.
>   > interfaces should encourage consistency
>   > increase maintainability, reduce no of errors
> - distinction of collections and non-collections for import/export behaviour
>   > PUT must result in non-coll, MKCOL in collection
> - allow to defined a set of import/export-handlers with a given order.
> - the different handlers must not rely on each other.
> - an import/export should be completed after the first handler indicates success. there 
>   should not be other classes involved in order to complete the import/export.
> - avoid huge configuration files and if possible, avoid program flow being defined outside of java code.
> - avoid duplicate configuration (e.g. resource-filtering), duplicate code, duplicate logic, that is 
>   hard to maintain.
> - additonal logic should be defined within a given import/export handler.
>   however, in case of webdav i see limited value of using extra logic such as addMixin or checkin, 
>   that are covered by  webdav methods (such as LOCK, VERSION-CONTROL or CHECKIN).
> regards
> angela

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira