On 13.03.2005 18:22:20 Victor Mote wrote: > Jeremias Maerki wrote: > > > > When you add vector (EPS and SVG) > > > into the mix to make a complete Graphic package, there are > > some other > > > things. > > > > Hmm, not so much. I think the implementation in FOP CVS HEAD > > is already a good start. As I said, it still needs some > > OK. I understand you to be saying here that you could take the FOP CVS HEAD > graphics code, and extract an interface from it that would not expose EPS- > or SVG-specific items in any way. That is definitely worth looking at, and > I'll try to do so within the next few days. > > > is already a good start. As I said, it still needs some > > improvements but mainly in other parts than this. > > You are talking here about implementation-specific things, right? IOW, > FOray's implementation vs. FOP HEAD's implementation? If FOP has made > improvements to the Graphic system, then I certainly understand that those > would need to be folded into FOray code before FOP would consider using the > FOrayGraphic package. But those aren't related to the aXSL interface, right?
Right. > > > The loggers in the servers are an oversight, and I have > > removed them. > > > However, I don't think there is a way to get rid of the logger in > > > FontConsumer. Because FontServer can serve multiple documents at a > > > time, it allows FontConsumer to tell it what logger instance to use. > > > > The Avalon way is IoC (Inversion Of Control). A FontServer > > implementation would simply implement the LogEnabled > > interface, as would the FontConsumer. In FontServer you can > > set the Logger on a FontConsumer through > > ContainerUtil.enableLogging. If a FontConsumer doesn't > > support LogEnabled this step is automatically skipped. The > > result: all this is hidden in the implementation and does not > > have to be exposed in the API specification. > > > > http://excalibur.apache.org/apidocs/org/apache/avalon/framewor > > k/container/ContainerUtil.html > > I'm confused here. FontServer doesn't *ever* "set the Logger on a > FontConsumer." The Logger instance that FontConsumer provides is an optional > feature that allows the FontConsumer to control where logging messages that > are specific to its document go. FontServer doesn't have to use it, and > FontConsumer can simply return null if it doesn't want that feature. IOW, > the control *is* inverted. (Remember that FontConsumer is an interface for > the *client* side and that one FontServer can server many FontConsumers). > But to provide that feature at all, how can FontConsumer tell FontServer > what logger to use without telling it what logger to use? That seems like a > necessary binding for that feature. Now I'm confused, too. I don't know what "can simply return null if it doesn't want that feature" means. Anyway, this is getting too much off-topic for this list, but we can continue off-list if you want. Anyway, if an object gets a logger from another object via a call to a getLogger() method, then it's not IoC anymore. > Now, if the real quibble here is about Avalon vs. Commons, that can probably > be resolved. I'm not up-to-speed on the issues there. And also it wouldn't > be too hard to provide both. No, it's not, as long as logging is not part of the API specification. Jeremias Maerki
