Return-Path: 
 <cocoon-dev-return-23403-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 65331 invoked by uid 500); 27 Feb 2002 19:40:48 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 65320 invoked from network); 27 Feb 2002 19:40:47 -0000
Message-ID: <3C7D36CE.6040902@users.sf.net>
Date: Wed, 27 Feb 2002 21:43:10 +0200
From: Antti Koivunen <anryoshi@users.sourceforge.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:0.9.8) Gecko/20020204
X-Accept-Language: en, fi, sv, fr, de, ja
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] Cocoon Web Applications
References: <3C79200A.64965AFD@apache.org> <3C7A336D.5070307@users.sf.net>
 <3C7B576F.F3689E46@apache.org> <3C7BD538.103@users.sf.net>
 <3C7CEE39.4A3C1BF3@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Stefano,

It seems that we pretty much agree on everything :)

(My first mail was mostly prompted by the use of the term "Web 
Application" and the "replacement for .war" impression that I first got 
from the message, but I realize that of course wasn't the idea.)

See below for more...

Stefano Mazzocchi wrote:
> Antti Koivunen wrote:
> 
>>Stefano Mazzocchi wrote:
>>
>>>Antti Koivunen wrote:
>>>
<skip/>
>>>>
>>>>Based on this, and other discussion on this list, I think it could be
>>>>useful to have some kind of installation/configuration tool for Cocoon.
>>>>It shouldn't be too difficult to implement with a clear definition of
>>>>core libraries, optional modules and dependencies (within the same
>>>>Cocoon distribution). At first, it could be a simple client app that
>>>>just does the following:
>>>>
>>>>  1. Download a set of files describing the Cocoon distribution.
>>>>  2. Select the desired modules (in addition to the core fileset).
>>>>  3. Check the dependencies (file-level, within the same distribution).
>>>>  4. Create the directory structure and download the required files.
>>>>  5. Create a sample sitemap and xconf for the selected modules.
>>>>
<skip/>
>>>
>>Well, more of a way of increasing the modularity and internal
>>consistency of the Cocoon distribution (as opposed to a complete package
>>management solution).
>>
> 
> ok

I wonder if this is something we should move forward on (not sure 
myself). On one hand, it feels like an intermediate (perhaps 
unnecessary) step to the full 'CWC' model, but on the other hand, it 
would be relatively easy to implement (version 2.0.3 - 2.1.0) and could 
make Cocoon more approachable. It would also provide (force) a clear 
definition of the core fileset and purpose of each 'component' (set of 
files) in the distribution. What do you think?

<skip/>
>>>
>>I'm all for increasing the modularity and extensibility of Cocoon, and I
>>like e.g. the concept of "skins", but I'm not sure that "Web
>>Application" is the right "unit" to use. I mean, it's just as likely
>>that Cocoon is used as a part of a single webapp, and I'd also like to
>>see the same modularity apply to other components, e.g. the likes of hsqldb.
>>
> 
> Of course. Modularity should be both 'vertical' (as with the 'skin'
> approach) and 'horizontal' (as with hsqldb examples or a portal
> application).... but I think my proposal solves both at the same time.

I think so too. We just have to define all the things that the modules 
may require and expose, e.g. one might just provide a simple role, while 
another one could include a sitemap and a mount-point, etc.

The Cocoon core could essentially consist of the 'XML processing 
controller' (in lack of a better term) and the 'CWC container'. I have 
to say I really like where this is going :) It could open a new array of 
possibilities for extensibility, component reuse, remote management, etc.

>>If CWA is defined to be "something that provides additional
>>functionality" for the Cocoon instance, then I think it's a good idea
>>(but perhaps better named to "Cocoon Web Component" or CWC, respectively).
>>
> 
> I like 'Cocoon Web Component', yeah, that's a good name.

Thanks, I like it too. Another even more general term would be simply 
'Cocoon Module', but it might not have the same marketing value (and the 
acronym would be confusing :)

<skip/>
>>
>>>But a package manager alone would not something that would please my
>>>search for a viable way to make cocoon web applications easily reused
>>>between different projects.
>>>
>>I agree (and would love to see that repository of Cocoon modules :)
>>
> 
> Exactly and I think that in order to make sure they interoperate in a
> nice and easy way, CWC polymorphism would be way cool!

Absolutely. Perhaps it's time to get back to the root of this thread and 
start defining things in detail :)

(: A ;)



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org