J.Pietschmann wrote:

> Victor Mote wrote:
> > 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

Hmmm. I missed that in the "goals" section.

> 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

This aspect of it could/should be entirely hidden from the user. IOW, I
wouldn't make the API more complex just to achieve this. Also, the
alternative to sharing shareable data and blocking thread access it to
duplicate the data and the processing of it. I'll certainly leave that issue
to you performance gurus.

> 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

I am not trying to implement multiple output options, but merely to make
sure we have the flexibility to do so. And frankly, I don't care if it ever
gets implemented. What *is* important, but on which I seem not to be making
any progress in explaining, is that each of the major processing tasks in
FOP should have a high-level controlling class that is responsible for it. I
see all four of the items you mention as being dependent on that.

> 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.

I agree with your first statement. On the second, I wouldn't like Jeremias's
proposal either if it caused a nuclear holocaust :-). I don't see why you
would suggest that my proposal would use more memory. I am quite sure it
would use less, but not enough to even mention.

> > 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.
> Why can't it be reused?

See answer in my response to Jeremias (which crossed your inquiry in the

> > 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.

Well, I don't think anyone is ever going to want to put a GUI on top of
Xalan, but I'll bet it will happen with FOP. The use case for FOP as it is
right now is fairly analagous to JAXP, i.e. a non-interactive process, but I
don't expect that to stay the same. Also, see my response to Jeremias about
the JAXP issue (also crossed in the mail). I'm not opposed to that pattern,
I'm just not sure it makes sense as our API.

Victor Mote

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to