On Wednesday, Oct 1, 2003, at 10:33 Europe/Rome, Stephen McConnell wrote:
[big snip]
Aside from all of that - I have been lurking here off and on for several months - and see overwhelming reasons for collaboration (and equally overwhelming reasons why this could be a bad thing to do).
I want cocoon 2.2 to implement cocoon blocks and I want it finished soon, less than 6 months (including the block librarian and all that). This doesn't give me much time to spend on discussing details with other projects.
I've looked at merlin/meta and I don't think how this can help us in the development (yeah, well, maybe steal some classes here and there, but the actual implementation is simply too different)
I believe it's much better if cocoon and avalon keep their focus (no matter how big the functional overlap is: the goal overlap is very small and the community overlap (in terms of active committment) is null) and keep working independently.
In the future, when both system are implemented, we'll see how things go and potential refactoring might take place.
In order to allow this, the only thing where I do see potential collaboration now is the block.xml descriptor schema... because we could well change /BLOCK-INF/ to /COB-INF/ but that would make the two systems diverge forever.
So, a few questions:
1) where is the DTD of your block.xml?
2) is that block.xml an avalon-wide thing or just merlin-related? [means: is that shared with Phoenix?]
3) how open are you/avalon to changes to this DTD?
At the end, if collaboration is not possible, it would still be possible, for containers, to react on namespaces to understand the different semantics of the markup used (ah, btw, merin's block.xml don't use namespaces, that is generally a good future-friendly practice)
--Stefano.
