My suggestion is that the first step be to look at the architecture for
Avalon 5, clean it up, and talk with your clients to see what we think (as
well as see what you think). Right now a lot of discussions are braked by
issues over how things are done now, rather than the right way to do things.
If people like the new approach(es), then iterate over the various phases of
architecture, design and implementation. I think that you'll find that if
Avalon 5 is substantially cleaner, leaner, easier, faster, etc., than Avalon
4 then we will not be unhappy. My guess is that the Framework interfaces
will be relatively stable except in a few areas; most of the major change
will be in how the profile-based container works.
Peter talks about doing more work on Avalon 4 as a learning exercise. Well,
you've already learned a lot, and you'll always be learning new things. The
profile approach to container building should enable more rapid development.
And no one has said that the code would be written from scratch. It doesn't
make sense to talk about code until you get to that point.
Plus, you'll have continued incremental changes on the 4.x series, a
migration plan for Avalon 5 (Avalon/V?), and use of the current containers
to prototype the new contracts. What's the downside?
This seems like a good time to for clients to prepare for a new approach to
Avalon, as well. James is preparing for a major overhaul (we'll see how
much actual re-coding we do, but we are giving ourselves permission to make
major changes). Sounds like Cocoon has a major release planned (did I hear
about a v3?). Don't know about other client projects, but the developers
ought to be invited to the discussion. All programs should be
client-driven, Avalon especially so since it exists only as a platform for
client code.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
