[ http://issues.apache.org/jira/browse/JCR-249?page=comments#action_12332582 ]
angela commented on JCR-249: ---------------------------- hi brian could you explain what is the use-case for having access to the resource in the import/export? the only command - as far as i know - that would currently need this information is the 'dirlisting' which does not really belong to the import/export... what it should do (and currently doesn't) is providing a list that corresponds to a PROPFIND with depth=1... but this is not a export that is driven by the repository items but rather by the dav-resource or itself, which knows about its members. kind regards angela > 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
