cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Regarding Excalibur XMLUtil and Store
Date Wed, 14 May 2003 00:46:26 GMT
on 5/13/03 7:07 PM Carsten Ziegeler wrote:

> Stefano Mazzocchi wrote:
>>but I wish the cvs diffs on those modules were sent *here* on cocoon-dev
>>instead that on a list where no cocoon developer is subscribed.
>>*this* is my point.
> Ok, I see your point - but only as a simple note (but I guess you already
> know this) - many cocoon developers are subscribed to the avalon list.

Good point.

>>>Perhaps the chance is bigger that a community will be built if the
>>>components are in Cocoon, but that's not for sure.
>>I would bet on it. Why? well, because itches develop more in a community
>>of people that cares about the technology uses.
> Yes, in generally I agree with you - but as the components in question
> are more or less complete and working I fear that this is not the case.

Another good point.

>>><half joke>
>>>With the same reasons, we could move avalon and the container 
>>>to Cocoon as well, because we care most of the development (especially
>>>when you think of the real blocks.
>>I'm not joking when I consider writing the cocoon block-aware container
>>from scratch without touching avalon code *exactly* to route around the
>>avalon community fragmentation problems.
> Yes, I know - and that's why I said "half joke" because I like to tend
> to agree with you on this one.

Good, I'm happy to hear that. :)

>>></half joke>
>>But, just curious: is there any action going on right now to build a
>>community around those components?
> I really don't know.

I think that Berin is asking for a little documentation. I think you
fully convinced me that it would be a good idea, instead of speding
cycles moving stuff, to write that and see what happens.

>>I'm beginning to challenge deeply that notion in my head. Code should be
>>where the community cares, not where it makes sense architecturally.
>>This said, I'm *dead serious* when I say that I'm considering writing my
>>own container from scratch for Cocoon 2.2 instead of using any
>>avalon-based one, even if it would be make perfect sense from a purely
>>technical point of view.
> Ok, I see your point - and I must confess that this makes sense from the
> cocoon point-of-view. Hmm, I have to think about it.

Ricardo and I are talking extensively about how to implement the
container for the Cocoon Blocks and the more I do, the more I think it
makes sense for Cocoon to have its own way first and see what happens next.

I mean: we all agree there is a great deal of overlap between the cocoon
blocks and the avalon blocks. in fact, only a little tag that indicates
where the sitemap is would be missing in the block deployment descriptor.

But *why* oh *why* should we coordinate with Avalon if we are the only
one who would use those things? Avalon deprecated the notion of blocks
because they thought it wasn't needed. Well, I strongly disagree with
that move and I still do, but I don't care about server frameworks
anymore, I just want to make users' life easy deploying cocoon stuff.

I have an itch and I'm going to scratch it. It's as simple as that.

Then, later, if the community dynamics ask for the outsourcing of the
cocoon block container to the avalon community and/or merging with
existing solutions, well, I'll be very happy to consider this, but as we
start, we need *COMPLETE* control on what we are doing, without having
avalon developers veto our decisions just because their architectural
notions are different from ours.

Now, don't get me wrong: I'm *NOT* suggesting we fork Avalon. The avalon
framework is here to stay and I will make an effort to follow the
official Avalon 5 paradigms if they ever emerge.

And, again, I DO NOT have problems with Fortress, what worries me is the
Phoenix vs. Merlin confrontation, since Fortress is a component
container, not a block container.

And merlin is only code oriented (no sitemap!).

And phoenix deprecated the notion of blocks (and Peter Donald doesn't
like them).

So, we are stuck and this has been the same for at least 12 months now,
with no sign of changes.

Result: screw them. A container is a not rocket science and we need
freedom of choice more than anything else at early design stage.

if it makes sense to extend Fortress, I will. If not, I won't and I'll
start from scratch.

And if any of you disagree and you want to beat me at the implementation
of cocoon blocks, you are my guest: the more angles we attack the
problem, the better.

>>I'm also aware this might create friction between the two projects. But
>>maybe this will also shake them up a little. We'll see when the time of
>>that comes.
> Yes, and I hope this time will come soon.

As soon as Cocoon 2.1 is out of the door I'll start working on it,
either as a branch or in the scratchpad.

>>>That those components don't have a real community is a 
>>different point and
>>>can imho not be solved by moving them back to Cocoon.
>>I'm tired of debating this. Like all avalon things, they become
>>religious and end up in personal deadlocks.
> Oh, this seems not to be fair, I don't see a religious debate here
> and I don't see a personal deadlock 

You are right, I apologize. You have been very open to all the issues
related to that code and you don't deserve that. My bad.

- in fact, if we decide to move
> the components back to cocoon than this is ok for me, but I still
> think we should try to solve the real problem - also I again must
> confess that I'm clueless how to solve that.

Write that little docs and make Berin happy. This is, after all, a step
that cannot possibly hurt.

> So, we could say, if we are all clueless how to solve the problem
> in the correct way, we have to choose "the wrong way" and move the
> components back. Hmmm, interesting situation.

No, i agree, let's use the energy in better ways.

>>I agree: let's move on to more important things.
> Good idea :) Perhaps we should simply wait a little bit and see what
> happens. Anyway *if* and only *if* we decide to move the components
> back to Cocoon, we should do this before a final/beta release of
> Cocoon 2.1.

I changed my mind: let the components remain there and let's work on
getting the release out of the door so that I can work on blocks and
free cocoon (and all of us!) from the chains of the servlet container :-)



View raw message