Return-Path: Delivered-To: apmail-jackrabbit-users-archive@locus.apache.org Received: (qmail 34337 invoked from network); 7 Jan 2009 14:45:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Jan 2009 14:45:33 -0000 Received: (qmail 1560 invoked by uid 500); 7 Jan 2009 14:45:32 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 1339 invoked by uid 500); 7 Jan 2009 14:45:31 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 1328 invoked by uid 99); 7 Jan 2009 14:45:31 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Jan 2009 06:45:31 -0800 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of tmueller@day.com designates 207.126.148.183 as permitted sender) Received: from [207.126.148.183] (HELO eu3sys201aog003.obsmtp.com) (207.126.148.183) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 07 Jan 2009 14:45:22 +0000 Received: from source ([209.85.218.11]) by eu3sys201aob003.postini.com ([207.126.154.11]) with SMTP ID DSNKSWS/7KHfyRzHblhfn+nVHemlwM23uOdg@postini.com; Wed, 07 Jan 2009 14:45:02 UTC Received: by bwz4 with SMTP id 4so23325576bwz.1 for ; Wed, 07 Jan 2009 06:45:00 -0800 (PST) Received: by 10.181.134.11 with SMTP id l11mr8942122bkn.73.1231339488056; Wed, 07 Jan 2009 06:44:48 -0800 (PST) Received: by 10.181.28.11 with HTTP; Wed, 7 Jan 2009 06:44:48 -0800 (PST) Message-ID: <91f3b2650901070644g27a3c76eq7d9ccad4c3e04ae7@mail.gmail.com> Date: Wed, 7 Jan 2009 15:44:48 +0100 From: "=?ISO-8859-1?Q?Thomas_M=FCller?=" To: users@jackrabbit.apache.org Subject: Re: Bridging DataStore and Web In-Reply-To: <494987E2.5050209@neovalent.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_133625_608173.1231339488031" References: <494987E2.5050209@neovalent.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_133625_608173.1231339488031 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I'm wondering if anyone has thought about a direct bridge between a web > server and a FileDataStore? You may be interested in https://issues.apache.org/jira/browse/JCR-1892 > It seems like the only things missing to implement such a thing are file > extensions in the data store The same binary object could be stored in multiple places (nodes) and thus have multiple file names and extensions. I believe file name and extension are attributes (that may change) and should not be bound to the content. > and a way to compute a filesystem path for an item in the FileDataStore. In some cases (DbDataStore) there is no path, and in some implementations it may not be stable. These would actually perform true caching functionality and could implement > various policies pertaining to caching (lifetime, etc). JCR-1892 should allow you to implement something like the HTTP ETag feature - http://en.wikipedia.org/wiki/HTTP_ETag - if this is what you need. Regards, Thomas ------=_Part_133625_608173.1231339488031--