From jackrabbit-dev-return-4871-apmail-incubator-jackrabbit-dev-archive=www.apache.org@incubator.apache.org Tue Dec 13 17:29:34 2005
Return-Path:
Delivered-To: apmail-incubator-jackrabbit-dev-archive@www.apache.org
Received: (qmail 27072 invoked from network); 13 Dec 2005 17:29:30 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
by minotaur.apache.org with SMTP; 13 Dec 2005 17:29:30 -0000
Received: (qmail 87702 invoked by uid 500); 13 Dec 2005 17:29:28 -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 87690 invoked by uid 99); 13 Dec 2005 17:29:27 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Dec 2005 09:29:27 -0800
X-ASF-Spam-Status: No, hits=0.0 required=10.0
tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Received: from [212.249.34.130] (HELO picanmix.dev.day.com) (212.249.34.130)
by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Dec 2005 09:29:25 -0800
Received: from eu-mail.day.com (eu-mail.dev.day.com [10.0.0.30])
by picanmix.dev.day.com (DAY) with ESMTP id jBDHT3U04844
for ; Tue, 13 Dec 2005 18:29:03 +0100 (MET)
Received: from [10.0.0.69] ([10.0.0.69])
by eu-mail.day.com (Lotus Domino Release 5.0.8)
with ESMTP id 2005121318290171:22006 ;
Tue, 13 Dec 2005 18:29:01 +0100
Message-ID: <439F04DD.8040806@day.com>
Date: Tue, 13 Dec 2005 18:29:01 +0100
From: Angela Schreiber
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: jackrabbit-dev@incubator.apache.org
Subject: Re: svn commit: r354818 - /incubator/jackrabbit/trunk/contrib/jcr-server/server/src/java/org/apache/jackrabbit/webdav/simple/ResourceConfig.java
References: <20051207174840.66169.qmail@minotaur.apache.org> <43981892.5060906@day.com> <439860D6.9020802@osafoundation.org> <439DF75B.9090907@osafoundation.org> <439E8C6A.1090605@day.com> <439E9BC8.3000309@osafoundation.org> <439EAB6C.1030009@day.com> <439EF8D2.3030405@osafoundation.org>
In-Reply-To: <439EF8D2.3030405@osafoundation.org>
X-MIMETrack: Itemize by SMTP Server on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 12/13/2005
06:29:01 PM,
Serialize by Router on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 12/13/2005
06:29:03 PM,
Serialize complete at 12/13/2005 06:29:03 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=UTF-8; format=flowed
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N
hi brian
Brian Moseley wrote:
> Angela Schreiber wrote:
>> you want a config that is good enough for any jsr170 implementation?
> that's the goal, yes.
here we go. that's the same discussion we had with the
'protected'. i'm talking about a 'simple' webdav server
and you pretend its a 'abstract concrete implementation',
which it definitely isn't.
> it's highly probable
> that every jsr170 implemetnation one would consider using for a
> scalable, performant, featureful internet server would implement
> nt:folder and nt:file.
and what about nt:unstructured? the most generic nodetype
you can even think of?
and what means highly probable?
you make assumptions... and you just pretend, that an arbitrary
jsr170 implementation would be such that it justifies your
hardcoded check.
>> your argument is - from my point of view contradictory.
>> with an arbitrary implemenation of jsr170 the list of
>> collection-nodetypes could equally grow to a theoretically
>> huge amount of nodetypes.
> that seems much less likely. the wide variety of types of resources
> stored in a webdav server dwarfs the types of collections that exists
> (precisely two in webdav+caldav).
again you are just making an assumption. in my usecase (CRX) there
are just 2 nodetypes (or actually its only one) that should be
displayed as non-collection resource and compared to it
there is a huge amount of nodetypes that should be displayed
as collections (e.g. remove the filter....). your needs are
maybe/probably different...
and there is yet another twist to the story: the
collection/non-collection part of the configuration is
just one part. you must also make sure that your import/export
can handle the collection/non-collection nodes. and this
should work for any jsr170 impl? hm.
if i start thinking about this, i realize that your are
really wrong, pretending that the 'simple' server is
'abstract concrete implemenation'.
if i wanted to such a thing, i would have choosen a different
implementation. and - surprise - i would have choosen
a different name. but i disagree that we can make the simple
server the magic-solution you are looking for, by adding
a lot of project specific ifs and helper methods and 'protected'
modifiers.
i guess, we are just talking about different things. i'm
consistently reconsidering the webdav library, while evaluating the
various enhancement request, for i think enhancements will
show the weeknesses of the design. and i have the impression
that you just want the simple server to be suitable for
your project but claim that with this changes we will have
the magic-solution.
i think we are arguing about different things.
kind regards
angela