Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 41517 invoked from network); 18 Feb 2010 12:08:12 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 18 Feb 2010 12:08:12 -0000 Received: (qmail 52158 invoked by uid 500); 18 Feb 2010 12:08:12 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 52111 invoked by uid 500); 18 Feb 2010 12:08:12 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 52103 invoked by uid 99); 18 Feb 2010 12:08:12 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Feb 2010 12:08:12 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of aklimets@day.com designates 207.126.148.87 as permitted sender) Received: from [207.126.148.87] (HELO eu3sys201aog101.obsmtp.com) (207.126.148.87) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 18 Feb 2010 12:08:04 +0000 Received: from source ([209.85.220.228]) by eu3sys201aob101.postini.com ([207.126.154.11]) with SMTP ID DSNKS30tjvb7YFVaNz9iKxCA5p3JZEGiX5YK@postini.com; Thu, 18 Feb 2010 12:07:43 UTC Received: by fxm28 with SMTP id 28so2011470fxm.11 for ; Thu, 18 Feb 2010 04:07:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.26.216 with SMTP id f24mr1427220fac.20.1266494861942; Thu, 18 Feb 2010 04:07:41 -0800 (PST) In-Reply-To: References: <510143ac1002170806n312514desd639aef826be0501@mail.gmail.com> <4B7CBC3B.7090803@gmail.com> Date: Thu, 18 Feb 2010 13:07:41 +0100 Message-ID: Subject: Re: [jr3] Plugin architecture From: Alexander Klimetschek To: dev@jackrabbit.apache.org Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 18, 2010 at 12:54, Guo Du wrote: >> First of all, I would define an API for configuration changes. This >> API could be the regular JCR API, and the configuration could be >> stored in special "system" nodes. > There are two kind of configuration apart from user data:node > definition and repository definition. > It's good to store node definition inside the repository and api to > manage changes. But the repository configuration shouldn't go inside > repository. Think about store db connection username/password inside > repository. Right. >> Extensibility of the importXML and exportDocumentView methods come to mind. > It may worth to redefine how we import/export. Xml should just be one > of format we support. I am not confident to use xml to export/import > GB/TB size data. ContentHandler could responsible for how the data > should be export/imported. The import/export XML methods are part of the JCR spec, so we cannot easily change their well-defined behavior. Instead, to support large dumps or backups, we should define an API at a lower level, that also ignores type and constraint checking to improve speed (if you know your dump is valid), like it is possible in many RDBMS. Regards, Alex -- Alexander Klimetschek alexander.klimetschek@day.com