On Mon, 16 Jul 2001, Berin Loritsch wrote: > What needs to be done is a Phoenix specific implementation for Cocoon's > Environment interfaces--and publish the Service interface and write > a descriptor. > > The hardest part is the Environment integration.
I'm still in the process of getting used to identifying the various components of Avalon seperately. For me Phoenix always was an integral part of Avalon and I can't see how to use Avalon without it - but Cocoon2 proves that Phoenix is just one server implementation using the Avalon framework. I'll get this straightened out in my head someday :) Perhaps it would be useful to take Cocoon apart into several blocks, so that various people could select the parts they want and build their own XML server. Once I learn more about Avalon, I'll be able to tell if it would make sense to get my hands on that. Our in-house applications that I'm working on take this approach. We have blocks like a JDBCManager, a JMXManager, a JNDIManager and so on. Then one app may be split into a "Writer" block, a "Reader" block, a "Controller" block etc. - it looks like fun to decompose applications like that and then re-use the blocks in other apps. How it plays out in the long run will be interesting to observe. In all my career of software development I've never managed to attain a sensible level of re-use, because usually when the apps worked, they were either rarely touched anymore or completely replaced one day. So to me ease of development (time to market) and ease of debugging (responsiveness to the market) was always more important than abstraction and re-usability. But I'm willing to try again, Avalon looks sufficiently sophisticated to give it a shot :) Thanks for the info, Ulrich -- Ulrich Mayring DENIC eG, Softwareentwicklung --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
