From jackrabbit-dev-return-1622-apmail-incubator-jackrabbit-dev-archive=www.apache.org@incubator.apache.org Sat Apr 09 18:43:46 2005 Return-Path: Delivered-To: apmail-incubator-jackrabbit-dev-archive@www.apache.org Received: (qmail 42125 invoked from network); 9 Apr 2005 18:43:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 9 Apr 2005 18:43:45 -0000 Received: (qmail 5000 invoked by uid 500); 9 Apr 2005 18:43:44 -0000 Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jackrabbit-dev@incubator.apache.org Delivered-To: mailing list jackrabbit-dev@incubator.apache.org Received: (qmail 4982 invoked by uid 99); 9 Apr 2005 18:43:44 -0000 X-ASF-Spam-Status: No, hits=0.4 required=10.0 tests=DNS_FROM_RFC_ABUSE,RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of benpickering@gmail.com designates 64.233.184.200 as permitted sender) Received: from wproxy.gmail.com (HELO wproxy.gmail.com) (64.233.184.200) by apache.org (qpsmtpd/0.28) with ESMTP; Sat, 09 Apr 2005 11:43:43 -0700 Received: by wproxy.gmail.com with SMTP id 68so2246567wra for ; Sat, 09 Apr 2005 11:43:41 -0700 (PDT) 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=Xcw/D++9hRKQ1Q1MC2b48As+zZTLRg1J+wkjD7iECAnpR3cQlDbrpmM56UL7e8XOoyw3J8q/mMcZmJ58TTMIocQ/zMKXnwmPbW2R3vAQra8eulNwN4PVO2sEyJKze7VyYDaXV73Hfg5kSWmzujtSCNamP77LlIlsC71j6CsIZBU= Received: by 10.54.55.6 with SMTP id d6mr709433wra; Sat, 09 Apr 2005 11:43:41 -0700 (PDT) Received: by 10.54.21.4 with HTTP; Sat, 9 Apr 2005 11:43:41 -0700 (PDT) Message-ID: Date: Sat, 9 Apr 2005 19:43:41 +0100 From: Ben Pickering Reply-To: Ben Pickering To: jackrabbit-dev@incubator.apache.org, tobias.strasser@day.com Subject: Re: webdav configuration api In-Reply-To: <8be7318805040909452c1edfd8@mail.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> <8be7318805040909452c1edfd8@mail.gmail.com> X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N I assume you're talking about import/export via WebDAV only. I'd be interested in thoughts in applying this to JCR objects in general -- the ability to define different interfaces for setting and getting data for some objects. Here's a Communique example. The table editor applet sets an Atom value that is a tab/newline-separated string. It's a nightmare to work with in code. Why not provide a TableAtom that provides getValue(x,y) and setValue(x,y,value) that manages the conversion to and from the complex string. You'd just cast the Atom to TableAtom to access the new features, and the basic getString() would obviously work just as before. This is an easy example and it's easy to think of many more applications: * validation * extracting media metdata * applying an XSLT stylesheet to XML data * helper functions for streaming data around (great for binary streams) and so on It would be nice to have this implemented in the repository, but obviously you could also make a decorating factory that could look up what type of atom it was and wrap the basic JCR object in something more useful. The former approach has the benefit of being easy to use from the client's perspective, but the latter is perhaps less invasive. On Apr 9, 2005 5:45 PM, Tobias Strasser wrote: > > 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 >--- > -- Cheers, Ben