I don't know Avalon, so I don't know what other facilities from there we are using or considering using.
Avalon is a great way to decompose a large system into components. The real advantage is that there can be different implementations managing the components. For example, we could build our own simple managers, more or less hardwiring what FOP components are instantiated and how they are composed into a working FO processor. That's good enough for testing and a simple CLI. Others could use ECM or Phoenix or whatever the Avalon guys throw out for efficient configuration and lifecycle management of the whole stuff in a server environment, with object pooling and caching (images and fonts) and so on.
I should probably move a bit faster in order to provide some working sample code so everybody can see how this could look like for FOP.
If we are involved in such considerations, we need to decide how we propose to support our 1.3 user base. The most recent discussions showed that a number of users face steep costs to upgrade to 1.4.
As for the 1.4 discussion: The jakarta commons list held it at some length a few weeks ago. It's choosing between Scylla and Charybdis: Using 1.4 gives a lot of functionality, thereby giving the project leverage to move faster rather than worrying about reimplementation of such functions. OTOH, it may lock out users on platforms which lag behind. There was also the consideration that many enterprises have servers based on 1.3 deployed, and upgrading a working service is usually frowned upon, even if a convenient path is available.
Given that FOP 1.0 wont be released until at least late this year, if not later, we could tell our 1.3 users to use 0.20.5 and declare 1.4 the minimum for 1.0.
J.Pietschmann
