Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: domain of tobias.strasser@gmail.com
 designates 64.233.184.204 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=gNyYaRJeUt2kGq64igmlH7dAdhJ3oQp5e/FIiupVG10NRtBlA+Ns8J3BnuzoiKUH34rmgq8S1G0YvHHB0Cpq5tQ3jUOfsWVUN2cP+KtLBZaYruU21kjLQ3gSUBbuwfS0LXEaZ588ORENQkppI6hrRFddajodY/AqwCobXVKn1ss=
Message-ID: <8be7318805040909452c1edfd8@mail.gmail.com>
Date: Sat, 9 Apr 2005 18:45:31 +0200
From: Tobias Strasser <tobias.strasser@gmail.com>
Reply-To: tobias.strasser@day.com
To: jackrabbit-dev@incubator.apache.org
Subject: Re: webdav configuration api
In-Reply-To: <4257CB9B.7050609@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
References: <425441AC.9050100@osafoundation.org>
	 <8be7318805040708276f211bbe@mail.gmail.com>
	 <425588DE.6090308@osafoundation.org>
	 <8be7318805040802455878f56b@mail.gmail.com>
	 <4257CB9B.7050609@gmail.com>

> 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

-- 
------------------------------------------< tobias.strasser@day.com >---
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 >---