Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <4301DCB5.1090402@apache.org>
Date: Tue, 16 Aug 2005 14:31:49 +0200
From: Sylvain Wallez <sylvain@apache.org>
User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: CoWarp (was Re: svn commit: r232855...)
References: <20050815185935.32798.qmail@minotaur.apache.org>
 <4300FE1D.2050606@dslextreme.com> <43018B96.9080904@apache.org>
 <4301AC67.8060001@apache.org> <4301B19D.90501@apache.org>
In-Reply-To: <4301B19D.90501@apache.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Carsten Ziegeler wrote:

>Sylvain Wallez schrieb:
>  
>
>>Carsten Ziegeler wrote:
>>    
>>
>>>For the demo portal, I replaced the authentication framework with CoWarp
>>>which provides imho a much nicer and cleaner way for plugging in your
>>>authentication mechanism.
>>>      
>>>
>>CoWarp is a 35 kb jar file containing 25 classes which seem highly tied 
>>to Cocoon and Avalon. Do you plan to move this code to the Cocoon repo?
>>
>>That would be IMHO a good thing to do to avoid the multiplication of 
>>small jars and give a better community oversight on this interesting stuff.
>>
>>    
>>
>If there is *high* community interest in hosting it at Apache I'm willing to
>move. In fact, lack of a community was one of the main reasons in
>creating Cowarp outside of Apache. Look at many of our blocks (incl. the
>famous authentication block), most of them do not have a community.
>They're a one man show (or sometimes a two man show). Apache is about
>communities, and I think as long as the project does not have a real
>community it should not be at Apache.
>  
>

Hmm... chicken and egg. How can one create a community around a one man 
show hosted as SF.net? Furthermore, can there be a community around a 
bunch of interface and their default implementations?

Not talking about the quality of the code, but about the interest these 
interfaces can generate, especially when they're so simple that they can 
already can be considered as "finished".

>So, my suggestion is, if there are people interested in it, speak up,
>lets create a comunity outside at Apache first and then move it.
>  
>

Again, I don't think there ever be a community around this. But just as 
we have a lot of dedicated sub-frameworks in Cocoon that became standard 
ways of solving problems (e.g. source resolver, input modules, multipart 
interfaces, or the new location framework), why wouldn't there be a 
standard simple abstraction for authentication and authorization in Cocoon?

>And I think currently we have way too many blocks and adding another one
>makes Cocoon even complexer. It seems everyone who has a good idea just
>adds another block (with no or minimal community). Just adding a jar
>dependency is much simpler from the complexity point of view.
>  
>

It's not really here about adding a new block, but about providing a 
simple and unified way of solving a common problem in Cocoon, which the 
current pipeline-based auth-framework doesn't seem to solve (I 
personally never used it).

The interfaces could be in core, along with the basic trivial 
implementations, and blocks could provide specialized implementations 
(e.g. JDBC, LDAP, JCR, etc).

>Another advantage is that I can use Maven for building Cowarp -
>something our build system does not provide. But for me using Maven is
>another prerequisite :)
>  
>

So let's switch Cocoon to Maven ;-)

Now why is it a prerequisite?

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://people.apache.org/~sylvain     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director