cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: Regarding Excalibur XMLUtil and Store
Date Wed, 14 May 2003 06:24:07 GMT
Stefano Mazzocchi wrote:
> 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.

I absolutely agree with the above - so this will be an interesting time ;)


> 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.

Count me in - you know, when you convienced me last year that blocks are
really cool (= a feature with hugh impact on the way of building
applications
etc), I tried from time to time to start an implementation, but never came
further than some minor concepts for the implementation.
This 2.1 release has cost a lot of man-power, so we must get it out
the door to start the blocks.

>
> Write that little docs and make Berin happy. This is, after all, a step
> that cannot possibly hurt.
>
Although the components are not from me and I might not be the perfect
fit to write the docs, I still have this point on my todo list as noone
else seems to be willing to write those docs. But it has really a very
very low priority right now - I'm trying to raise this priority and
perhaps I can come up in the next weeks with some docs. Perhaps someone
else is faster :) (Then I would owe that guy a beer)
(The weeking is already occupied with testing my new apple 17inch powerbook
that arrived finally on monday and as I'm not at home is still lying
there and waiting for me, then I have to install my small 'home theater' and
have to put all the cables, speakers etc at the correct places in my
living room and have to take care that my wife is still pleased with
the result :) and the new DSL router has arrived waiting to be installed
as well, so...)

> 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 :-)
>
> Deal?
>
Deal!

Ehmm...but...I prepared the following text minutes before a read your
reply, so I have to put it here as well:
>>prepared text<<
Ok, after sleeping over this topic (well, if you can tell a 4 hour
sleep after some discussions and a few beers with Giacomo, Pier,
Massimo and some others "sleep"), I have made up my mind and
want to revert my -1.

Thinking about it, moving things etc. is not the real
problem for me, but package renaming is an incompatible change.
So what do you think about keeping the avalon package names, *if* we
move the components back to cocoon.
So we don't have incompatible changes and could possibly move
them back in one year if it makes sense by that time (just a silly idea).
>>end prepared text<<

But as we have our deal, we just keep everything as it is, add
some docs and see what happens.
Then we throw 2.1 out of the doors, implement this blocks thing
and will have an even more rocking release lying under the
christmas tree :)
Sounds great to me!

Carsten


Mime
View raw message