From: Stephen McConnell [mailto:[EMAIL PROTECTED]
Leo Sutic wrote:
Can Avalon/Meta be the framework-wide metainfo package?
Sure. In its
current form? I don't really want that.
And here is the where things come down to the metal.
* we have agreed to one architecture, one implementation, one platform
The only product release specifically dealing with meta-info management is the Avalon Meta package. It can change, it can evolve, it can be replaced - but under the principals of one architecture, one implementation, one platform - it cannot be duplicated. Implications of this very important - it means that is someone has an itch, there is one place to focus that itch. The consequence is that itches start to take focus, effort consolidates, products improve.
It also means that we start with Avalon Meta in its current form instead of the traditional approach, which is that everyone brings their ideas to the table, and then we form a solution from those.
Yep.
The risk we have here is this: It is a common negotiation tactic to say "hey, I've done a quick draft, why don't we start from it and let it evolve". Unsurprisingly, the end result almost always end up looking like the start. I think it's called the "anchoring effect".
I know - there are benefits and there are downsides.
The risk is thus that if we began with Avalon Meta in its current form, we'll end up fairly close to Avalon Meta in its current form, without having explored other solutions that differ radically from it.
I'm not so hesitant. What we do have in the avalon-meta package is a real good (IMHO) api and good separation of spi interfaces and implementation code. And this means that there is lots of scope for total implementation replacement (taking into account some realistic constraint points).
And that's the problem I have with your approach. Acknowledging Avalon Meta as the framework-level metainfo package and working from there
forces any change to be incremental from the current state of Avalon Meta, thus constraining us needlessly.
I view things a little differently.
1. recognize and agree that we have an initial reference point 2. don't be afraid of version n+1 3. don't be afraid to talk about a fork 4. break out concerns we discuss relative to API versus implementation
If I were to take a cutting another implementation of meta I would do things differently - but I would make sure that:
(a) the current XML format is supported (b) the solution maintains compatibility with the Type API
Outside of that - anything goes.
For example, I'd like to push some ideas from Commons-Attributes into
the future metainfo package to solve issues that people have had with
Avalon Meta - for example the difficulty of extending the set of recognized tags, the need to use XML parsing, etc...
The domain model looks pretty fine to me, though.
I'm positive we have very similar objectives with respect to the end result. I'm even rather sure that a face to face discussion would validate this and confirm similar if not identical priorities in terms of platform requirements.
Cheers, Stephen.
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
