Stephen McConnell wrote, On 18/07/2003 9.42:
...
Bottom line is that I don't think we should try to have Merlin deprecating Fortress - instead I think we have Fortress deprecating things progressively relative to a standard containment architecture. The difference is that Fortress would continue to exist to handle the delta between what is established as standard, and what is specific to the ECM legacy....
Basically I envisage a future in which the internals of Merlin are changing, evolving and adapting as we move towards the "perfect" solution. I should point out that I think that *release* should not be interprited as an *we-have-to-maintain-Merlin-API-as-is*. Instead - the questions of what *release* actually means should discussed in a lot more detail (and on the dev list - not here). In particular, we need a release plan that outlines what aspects are volotile, what aspects are not.
Ok, let me try and rephrase in a more succing way what you are saying: ;-P
1 Merlin/the evolution of it, will be the next Avalon container 2 Fortress will not go away because it will deal with legacy components 3 Merlin needs milestone releases to get more feedback
I agree with 1, 2.
I'd add another point: to become (1) Merlin must adopt common standard contacts, which it currently does not always do, as Berin *correctly* pointed out (hence the "divergent" bad work that got you more concerned than IMHO was in the original intentions).
Then we should discuss a bit point 2 (esp you and Berin)
a - What does Fortress provide as legacy that Merlin will not provide and why?
b - What about the *implementation* merits of Fortress that Merlin lacks? Those would have to be ported as well.
-- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) ---------------------------------------------------------------------
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
