J Aaron Farr wrote:
The problems with the 'assimilated' approach are
- From a component author perspective the Avalon framework is the point of contact between my personal development and all this Avalon stuff.
- There are many other projects and applications which only use the Avalon framework. These groups will be interested in framework documentation which discusses it in a more 'standalone' context.
This became (as expected) a heated move, but Avalon can not, and should not, center around a part that historically been more important, but slowly and surely looses its relative importance.
As for the future of Avalon Framework (from the independent vendor's perspective, so to speak) is fairly straight forward and 'safe'.
Expect an AF 4.3 (Q3?), with minor additions and likely some more deprecations.
Expect an AF 4.4 (Q4?), with an added Availability contract, which I am very keen on getting done.
Expect an AF5 (next year), which is largely compatible with AF4, where the deprecated stuff is removed.
Expected stuff to be taken out by AF5; Composable and associates, ReXXXable and associates, ThreadSafe and associates, Selectors and the semantics surrounding it.
I can imagine that an AF4 compatibility layer could be created for some demanding users, and I am fine with that.
Cheers Niclas
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
