From users-return-14265-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org Tue Feb 09 08:16:13 2010 Return-Path: Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: (qmail 77860 invoked from network); 9 Feb 2010 08:16:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 9 Feb 2010 08:16:13 -0000 Received: (qmail 47887 invoked by uid 500); 9 Feb 2010 08:16:12 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 47800 invoked by uid 500); 9 Feb 2010 08:16:12 -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 47789 invoked by uid 99); 9 Feb 2010 08:16:12 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Feb 2010 08:16:12 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_HELO_PASS,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: 216.139.236.158 is neither permitted nor denied by domain of dotchev@gmail.com) Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Feb 2010 08:16:03 +0000 Received: from joe.nabble.com ([192.168.236.151]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1NelG1-0003kV-WA for users@jackrabbit.apache.org; Tue, 09 Feb 2010 00:15:41 -0800 Date: Tue, 9 Feb 2010 00:15:41 -0800 (PST) From: Peter Dotchev To: users@jackrabbit.apache.org Message-ID: <1265703341989-1474048.post@n4.nabble.com> In-Reply-To: <8641fd7c0707100617j6032c04fm8df50fcde7d70222@mail.gmail.com> References: <510143ac0707100136t20b1d1b0ybb60f66cf381f64d@mail.gmail.com> <510143ac0707100149m56b39fdi3cd1d965fa4e1d1c@mail.gmail.com> <8641fd7c0707100158s5b8547afy4423a67e65effd92@mail.gmail.com> <510143ac0707100216sffb9f86r4af002bcb1852e28@mail.gmail.com> <5f211bd50707100243k1b3808d4ndd361096331d94be@mail.gmail.com> <510143ac0707100255u431c1590h6bd2bb91a5142f15@mail.gmail.com> <510143ac0707100348h43afe171ud63eabef10354057@mail.gmail.com> <8641fd7c0707100617j6032c04fm8df50fcde7d70222@mail.gmail.com> Subject: Re: DM Rule #4: Beware of Same Name Siblings. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Hi, After reading this whole discussion, I'm still not convinced that SNS are bad. If they are inefficient, that is an implementation issue that should be addressed in the proper place. As seen in this discussion even if you want you can't come with really meaningful paths due to name conflicts and changes over time. Actually if you want to avoid SNS you have to come up with (locally but still) unique names. - These are essentially id's which contradicts rule #7 - It gets more complicated as you have to implement some algorithm to generate unique names and most probably you have to deal with concurrency issues. Is it really necessary? I would not consider path stable, so I use UUID in URLs. While meaningful paths would be nice I don't think they are so important. I think in most cases users are not interacting directly with the repository but with some (web) application which uses the repository as storage back-end. Generally I think the concept here is pretty simple. I have a collection with a bunch of entities. I don't need and don't want to name them. Each entity has some properties. I just want to add, remove, query and edit them. There should be a straightforward way to achieve this. Best regards, Peter -- View this message in context: http://n4.nabble.com/DM-Rule-4-Beware-of-Same-Name-Siblings-tp514376p1474048.html Sent from the Jackrabbit - Users mailing list archive at Nabble.com.