Nicola Ken Barozzi wrote:
Oh, c'mon, Nicola, don't be a such a PITA. We havn't released anything with 'block' attached (and for this reason), there is nothing carved in stone and Peter has valid points about name clashes.Peter Donald wrote:On Tue, 26 Nov 2002 15:31, Peter Donald wrote:BTW - it may be best not to name them "Blocks". Phoenix already has the notion of blocks which is vastly different from what Cocoon proposes to use the term for. It would confusing to name two different concepts with identical names. Given that Phoenix (and it's predecessor) has been using the term since before I was involved in Avalon it may be best to rename Cocoon blocks to something else so as to avoid confusion from users.On Tue, 26 Nov 2002 11:04, Stefano Mazzocchi wrote:I agree with you that ECM is crappy code. And you know that in order to
implement Cocoon Blocks, we'll need a much more modern (and thought-out)
container and that in order to be able to do that, we might even allow
some back-incompatible changes (for something like Cocoon 3.0) where it
does make sense to break compatibility.
Suggestions;
* Cocoon Packs (foo.pak or foo.pax or foo.cpk)
* Cocoon Archives (foo.car)
* Cocoon Modules (foo.mod)
* Cocoon Libraries (foo.clb)
* Cocoon Bags (foo.bag) (as in Bean Bags)
* Cocoon Tins (foo.tin) * Cocoon Boxs (foo.box)
It's (almost) too late, we already have a blocks dir in CVS, and have been talking a lot about "blocks".
Probably the extension will be ".cob"
But the reason why I called them blocks was *intentionally* to express relationship with Avalon blocks (but wheren't you deprecating them, BTW?)
Cocoon Blocks represent the idea I had about blocks a while back moved into the cocoon world and I still think it's a good idea.
Ah, btw, this is probably the wrong list to talk about cocoon-related stuff.
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
