> I don't see how common chain would help in the import/export task :(. > AFAIK chain is used to run a sequence of commands but in this case only > one command should handle each request, there's no complex processing > flows. It would be useful for performing custom operations before and > after import/export but I don't see it as a common requirement. Am I > missing something?
well, the webdav server needs some mechanism to create jcr-items from a webdav resource, and vice versa. the most generic way is to create a nt:file + nt:resource for a non-collection resource and a nt:folder for a collection. an example for a more sophisticated import is deserializing a XML file, thus allowing other applications to search and manipulate the desrialized XML in the repository. another example is to extract more information from a imported resource, eg: ID3 tags from a mp3-file, format, colorspace, dimensions from a image etc. we need a plugable mechanism for import/export. we thought of a chain of handlers, that sequencly are asked to perform the respective import or export operation. instead of building an own implementation of such a framework, commons-chain seems to be a good alternative. i made first steps in implementing those handlers using commons-chain, and it seems worth to follow this path. imo, one chaining-framework is as good as something else. if jakarta provides such a framework it makes sense to use this one. the need for configurable, plugable import/export handlers is undoubted. as first step, we will provide those handles, using commons-chain. but if it shows, that there is a better alternative, i think we can easily switch to something else. cheers, tobi -- ------------------------------------------< [EMAIL PROTECTED] >--- Tobias Strasser, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 -----------------------------------------------< http://www.day.com >---
