I guess I don't understand the need for FOProcessorFactory, which seems to be an unnecessary complication for the user.
It has something to do with the GoF Factory pattern. This means you can choose the implementation of the FOProcessorAPI by setting a Java property, or some similar mechanism at run time instead of choosing it at compile time. Granted, this seems of not much use given that FOP will be the only implementation at least for some time. There is another aspect: the FOProcessorFactory holds a default configuration and is a mechanism to quickly create preconfigured FOProcessor objects. You just can't use a single FOProcessor, because it holds a state while rendering and is therefore not MT safe in itself. Unless you can live with blocked threads this means you have to create a FOProcessor for every thread. Furthermore you might want to keep FOProcessor objects some time around after rendering has finished in order to inquire the number of rendered pages or whatever useful data the processor can supply then.
RenderContext is only useful if you are trying to reuse an AreaTree for multiple output options. I am frankly confused right now about whether the dev team even wants to try to do that.
I think we have a few slightly more pressing problems: - getting layout up to conformance - make FOP MT safe - improving the API to ease embedding (including Java2D embedding) - improve performance and reduce memory consumption
Adding multiple output streams is certainly fun but I suspect the bulk of the current users would be more interested in one of the points above. And somehow I have the feeling that your approach could easily get in the way, in particular I wouldn't like if it would *increase* memory usage in general.
Why can't it be reused?It looks like you are pushing the data that I envisioned in Document and RenderContext down to RenderType/FOPResult. The net effect is that it can't be reused.
1. complexity. In addition to the Factory issue already mentioned, I think there is some benefit to arranging the data more intuitively for the user.
Users should be able to recognize certain patterns, like the ones used in JAXP.
J.Pietschmann
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
