From users-return-4458-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org Tue Aug 07 22:42:51 2007 Return-Path: Delivered-To: apmail-jackrabbit-users-archive@locus.apache.org Received: (qmail 63197 invoked from network); 7 Aug 2007 22:42:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Aug 2007 22:42:50 -0000 Received: (qmail 70516 invoked by uid 500); 7 Aug 2007 22:42:48 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 70504 invoked by uid 500); 7 Aug 2007 22:42:48 -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 70491 invoked by uid 99); 7 Aug 2007 22:42:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Aug 2007 15:42:48 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of quintesse@gmail.com designates 64.233.182.191 as permitted sender) Received: from [64.233.182.191] (HELO nf-out-0910.google.com) (64.233.182.191) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Aug 2007 22:42:46 +0000 Received: by nf-out-0910.google.com with SMTP id g16so516196nfd for ; Tue, 07 Aug 2007 15:42:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=pWfl+oyFCBztypNFAt/ThIzkZ2lYozIgmx4R0jAySr6Jg6uU6O5X0+QBkrqE8a5Mu97kFj5jXpDekPwQ5KGY+XLlCGYjWa+OTuo9fFcKboP3Dkw50qvSx2eG/nt8XVud6kRvc9QVwJW6raFddr+6K+WR76df3kt+ZSlOsQktNho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=VYZdgGVfrzOUFckqOTfBXGXwOtUfxnWbHW47dSd9otirDflh5Xovx0u1vN3Ns0YIK3DipF7WjYNDMEMXgq0mZHf7FAWYQsTk4NeU+YWPJeQuWzChFshNwckj3wkijQ7SWPaKqSHT3h6zQ0XrnDvJSLmIQwaj5MNjncMD9K3FRzA= Received: by 10.78.190.10 with SMTP id n10mr1997480huf.1186526544535; Tue, 07 Aug 2007 15:42:24 -0700 (PDT) Received: by 10.78.145.7 with HTTP; Tue, 7 Aug 2007 15:42:24 -0700 (PDT) Message-ID: <8641fd7c0708071542j36192317rba9c2526a80d2762@mail.gmail.com> Date: Wed, 8 Aug 2007 00:42:24 +0200 From: "Tako Schotanus" To: users@jackrabbit.apache.org Subject: Re: Questions regarding nt:file and nt:folders In-Reply-To: <12040465.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_90909_30426922.1186526544501" References: <18eb6ef00708070929o22431f6g3b676c0effcae6f1@mail.gmail.com> <12040465.post@talk.nabble.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_90909_30426922.1186526544501 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 8/7/07, qcfireball wrote: > > > I hope this provides you some clarity. > > In reply to Bob's question (his text omitted for brevity): > Here are 2 scenarios involving files. One involves a single file, the > other > an arbitrary number of files. The format of the text is: > node-type|node-name, with children underneath, indented: > > nt:file| > nt:resource|jcr:content > (p) jcr:encoding=... > (p) jcr:mimeType=... > (p) jcr:data=0x...... (binary content) > (p) jcr:lastModified=... > > nt:folder| > nt:file| > nt:resource|jcr:content > (p) jcr:encoding=... > (p) jcr:mimeType=... > (p) jcr:data=0x...... (binary content) > (p) jcr:lastModified=... > nt:file| > nt:resource|jcr:content > (p) jcr:encoding=... > (p) jcr:mimeType=... > (p) jcr:data=0x...... (binary content) > (p) jcr:lastModified=... > > It seems to me, what you want to version is the nt:resource, NOT the > nt:file. I am not sure what function or responsibility the nt:file node > provides, but as you know, the actual content resides in the nt:resource. > It seems reasonable that you would want to version the ACTUAL item that is > varying, not the node that contains it. You have mentioned this in your > post. Mentioned elsewhere, I cannot find it right now, David mentions > that > in his own use of the JCR, he rarely (if ever) extends nt:file, but > regularly extends nt:resource. Unless of course you want to keep track of folder and file renames. I would be inclined to have an implicit trust in his statement on this. > Maybe naive, maybe not. So, it would seem that an extension of > nt:resource > would be preferable. > > > I have a couple additional questions to this issue of files/folders. > > 1) why the additional level of indirection with nt:file? If this is > analogous to a filesystem, the file IS the file. What is the benefit of > nt:file and nt:resource existing as separate entities? I imagine the reason is "content re-use", an nt:resource is an anonymous item that could possibly belong to an nt:file and several nt:linkedFile nodes. 2) What is involved in creating an extended nt:resource node type? Is there > a document discussing how to do this? Or would I be able to figure this > out > by inspecting the source code? I think it's nothing more than registering a new node type, like this for example: [foo:i8nResource] > nt:resource - jcr:language (STRING) 3) Because I know I will be asked, if extending nt:resource is a frequent > occurence, why is there not a "stock" version that would allow some > additional capabilities, such as extra arbitrarily named/typed properties? > In the new world of development where Enterprises want to use more "off > the > shelf" software and less custom written software, why would this not be a > part of the spec? Some folks, perhaps in our Enterprise, would view this > as > a deficiency rather than a benefit, due to the possibility of breakage as > updates occur. I have no idea, sorry. Cheers, -Tako ------=_Part_90909_30426922.1186526544501--