Hello Jeremias. > Can we take a step back? Let's look at the possibilities: > > 1. URI resolver: ... > 2. URI to InputStream resolver: ... > 3. URI to FopImage resolver: ...
Thanks for the round-up, i think thats make the needs clearer! These points are the logic extension of my initial proposal. > Wouldn't it solve any possible requirement to provide a > central registry > in FOP where implementations of these interfaces (all three) are > provided? By default, FOP provides its own basic > implementations and our > customers (Cocoon for example) could plug in their SourceResolver and > CatalogResolver as necessary. Yes! This would be perfect. > Actually, that was what I originally planned to do by > introducing Avalon > (Framework). Its Serviceable/ServiceManager pair would have provided > this infrastructure (allowing easy interfacing with Cocoon). I don't > think it's a big problem to write some basic infrastructure to provide > this (extending FOUserAgent or writing some FOPEnvironment class). > Avalon would provide that already, as would probably other frameworks > (such as Hivemind). In the end it depends on how much we will want to > write ourselves and not depend on other libraries. Given the recent > events in Avalon-land (and around it), I don't have a problem > with going > our own way although it doesn't sound ideal to me. Batik has done the > same. After a browsing a bit more in the FOP wiki i found this interesting proposal http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization together with Bugzilla Bug #14419 (seems two years old). Is it still planned to avalonize FOP? Regarding the last postings i suppose it is not, but i do not know if this is the opinion of the whole FOP communiy. (I personally would still prefer the avalon-way, btw). I think FOP desperately need a central resolving mechanism of any kind. Concerning the further steps i've two questions: 1. Are there any deeper thoughts already done for the next major release of FOP concering source resolving? (i've had not yet the time to take a deeper look into the codebase) 2. Is there any chance or need (besides of mine) to get a very primitive resolving capability built in the existing maintance release of fop (0.20.5)? - because it still seems a long way for the next major release. Stefan
