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.
J.Pietschmann
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
