Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3E5F75D0.1080507@apache.org>
Date: Fri, 28 Feb 2003 15:44:32 +0100
From: Stefano Mazzocchi <stefano@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.3b) Gecko/20030202
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [New build system] Status of samples
References: <D3C02D6B-4B13-11D7-90DA-0003935AD2EE@media.demon.co.uk>
In-Reply-To: <D3C02D6B-4B13-11D7-90DA-0003935AD2EE@media.demon.co.uk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Jeremy Quinn wrote:
> 
> On Friday, February 28, 2003, at 10:50 AM, Stefano Mazzocchi wrote:
> 
>> Finally, I think the Cocoon build should also allow you to build your 
>> own cocoon web site. In this case, your stuff should becomes nothing 
>> different from a microblock. (please, don't start using this 
>> terminology, it sucks, it's just to give you the idea)
>>
> 
> I completely agree. (but I have no suggestions for a solution, sorry)

don't worry, we'll come up with a solution collaboratively.

> One of the trickiest things to do with Cocoon is to update an existing 
> webapp with a new version of the code and configs. 

Yep!

> The configs pose the largest problem. 1) they change often, 2) you often have to modify them 
> with your own datasources (etc.).

A solution for this is already designed into the COB concept since each 
COB (the real cocoon blocks, not the static poor-man version we have 
today) will have their own sitemap, configurations and roles.

And they will be exposed to those blocks that depend on these transparently.

But we need a much better avalon container to be able to support this 
concept.

> While it is important to have a simple build, so you can see it works 
> out of the box (as we have now), I am looking at the scenario whereby a 
> user wants to update an existing cocoon installation with a fresh update 
> from CVS, first for testing, then for production. Or wants to build an 
> installation of samples.
> 
> so I see 4 common scenarios :
> 
> 1) a 'test' build and run (we have that and it's great!)

yes, I wanted to reach this point first and I think I did.

> 2) a 'samples' build and run

This is the next thing to tackle.

> 3) an 'update' build and run (on an internal testing port)
> 4) an 'update' build and run (on a production port)

Without a complete redesign of the way Cocoon handles components and 
internal dependencies this is going to be tricky to say the least. Hacky 
for sure.

During the last few months I thought about forking Cocoon and work on my 
own tree until a new architecture for block loading was in place, but I 
feared that this move would have created too much social friction (been 
there, done that), so I'm choosing an evolutionary path which might be 
rather annoying for those working on the tree (Carsten already expressed 
his feelings about this) but keeps the community together.

This evolutionary path goes thru creating a cleaner build system and 
really factors things out on a dependency base.

I do have an architectural solution that will solve *all* your usability 
problems and I outlined it in my COB proposal.

But I want to release Cocoon 2.1 before even attempting to do such a 
major refactor. At that point, 2.1.x will solidify while the brave men 
between us will tear everything apart and start over with Cocoon 2.2 on 
a new CVS module.

When I say "tear everythign apart" I don't want you to worry: cocoon is 
so well architected internally that we can redesign everything inside 
without having to touch *ANY* of the contracts with the outside.

This is why I see this as Cocoon 2.2 instead of 3.0: there will be 
complete component-level back compatibility and your webapps will work 
just fine.

But this is the future.

For now, what we can do is to refactor things so they are cleaner.

For the 'update' scenario, we'll do some hacks for now while we work on 
a serious solution for the next generation.

> I am sorry I do not actually have any solutions, I am just thinking 
> about what I reckon people want to be able to do easily.

The solutions are already there, Jeremy, trust me.

> Thanks for all the hard work you are putting in.

You're welcome.

-- 
Stefano Mazzocchi                               <stefano@apache.org>
    Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------