API stabilization

[Jeremias Maerki <de...@jeremias-maerki.ch>]

For the 0.90alpha1 release I've deprecated the Fop class' constructors
with the integer parameter for renderer selection. Is it ok if I remove
them before the "beta" release? Or does anybody still prefer the
integers over the MIME type approach?

I'm reasonably happy with the API now and don't see a big need to change
anything right now.

The only thing I still have on my TODO list is the split of some kind of
"environment or factory class" (holding references to font configuration,
caches, registered extensions etc.) from the FOUserAgent. This would
speed up initialization for systems that do multiple rendering runs in
one JVM session. An example: The FOTreeBuilder currently reregisters all
extensions each time at the beginning of a rendering run.

This thing could be implemented as an optional parameter to the
FOUserAgent or as a Factory for Fop instances (the latter approach more
closely following the JAXP pattern). Or a mixture of both. I'm not sure
exactly how to do this, yet. Still thinking... And I have yet to go over
out previous notes on the API again. Anyway, the API has to be
stabilized now. Too many incompatible changes will make people angry.


Jeremias Maerki

Re: API stabilization

[Chris Bowditch <bo...@hotmail.com>]

Jeremias Maerki wrote:

> For the 0.90alpha1 release I've deprecated the Fop class' constructors
> with the integer parameter for renderer selection. Is it ok if I remove
> them before the "beta" release? Or does anybody still prefer the
> integers over the MIME type approach?

I'm happy for the integer constructors to be removed.

> 
> I'm reasonably happy with the API now and don't see a big need to change
> anything right now.
> 
> The only thing I still have on my TODO list is the split of some kind of
> "environment or factory class" (holding references to font configuration,
> caches, registered extensions etc.) from the FOUserAgent. This would
> speed up initialization for systems that do multiple rendering runs in
> one JVM session. An example: The FOTreeBuilder currently reregisters all
> extensions each time at the beginning of a rendering run.

Good idea, it would help performance a bit.

> 
> This thing could be implemented as an optional parameter to the
> FOUserAgent or as a Factory for Fop instances (the latter approach more
> closely following the JAXP pattern). Or a mixture of both. I'm not sure
> exactly how to do this, yet. Still thinking... And I have yet to go over
> out previous notes on the API again. Anyway, the API has to be
> stabilized now. Too many incompatible changes will make people angry.

Yes I agree.

Chris

Re: API stabilization

[Andreas L Delmelle <a_...@pandora.be>]

On Dec 16, 2005, at 08:13, Jeremias Maerki wrote:

> For the 0.90alpha1 release I've deprecated the Fop class' constructors
> with the integer parameter for renderer selection. Is it ok if I  
> remove
> them before the "beta" release? Or does anybody still prefer the
> integers over the MIME type approach?

No objection to removing the integer constructors here.

> I'm reasonably happy with the API now and don't see a big need to  
> change
> anything right now.
>
> The only thing I still have on my TODO list is the split of some  
> kind of
> "environment or factory class" (holding references to font  
> configuration,
> caches, registered extensions etc.) from the FOUserAgent.

Agreed, with some reservations. See recent post on fop-users: there  
seem to be users --well, at least one-- who require the use of  
multiple configurations. As long as the user-config doesn't become  
'static' for all runs within the same session: +1.

Cheers,

Andreas