How would you propose structuring Avalon? My strawman is that we have:
very similar to what you have laid out..
- Frameworks (contracts, TCK, optional shared implementation)
Contracts being Hedman-style .. piecemeal, not "all or nothing"
- Components (library of reusable parts, which ought to increasingly consist of adapters, that run on most containers -- the agreement ought to be that we start by documenting which ones run in which container(s), strive for WORA, and move as quickly as practical to a state where the container can determine whether or not it and the component are compatible).
- Containers
agreed.
More importantly, how would we deal with the Community issues? Would we
need to establish separate mailing lists? How would we manage the contracts
area?
That's the kicker. We used to have separate mailing lists for phoenix and components. The "problem" was that Phoenix development happened on the phoenix list and not everyone was subscribed. Thus everything was forced back into a single dev list.
Although I can't speak for everyone, the environment at Avalon has been gradually wearing me down (witness most everyone else with a long Avalon history that has fled). Thus "extracting" the code bases that I care about and leaving the community drama behind is very appealing to me.
-pete
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
