Victor Mote wrote:
I'm not opposed to Avalon, but I might be if I understood it.

Well, the good message about Avalon is that it can make development for much easier. The bad news is that if too much of Avalon is exposed in the APIs intended for common usage, it will drive many potential embedders away.

I think if we want to use Avalon internally (and there are
interesting use cases, for example the Hyphenator), it would
make most sense to provide an Avalon component shell which can
be also used with a simple factory pattern similat to TrAX.
Have a look at the Avalonization Wiki.

It probably
seems lazy that I am not up to speed on it yet -- I have tried a couple of
times to get the big picture from the doc, but concluded that I won't get my
arms around it until I use it (IOW, the doc wasn't very helpful).

Amen, brother.

If the static construct and Avalan are mutually exclusive, the former seems
far less invasive, and easier both to implement and un-implement.

Well, static data often interferes badly with multithreading. We can use it in the CLI, but in the core which is intended to be possibly embedded in multithreaded long running server environments should it is best to avoid them. Even if you can arrange to synchronize properly (not as easy as many people think), blocked threads on shared ressources will almost certainly generate angry comments.


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]

Reply via email to