Re: Finally finalizing the FOP API
Ok, the necessary changes except for the deprecations are done in the branch. On 13.02.2006 10:16:25 Jeremias Maerki wrote: snip/ I decided that I will implement my proposal in a new branch. There, everyone can have a look at the real thing and we'll adjust as necessary to make everyone happy. snip/ Jeremias Maerki
Re: Finally finalizing the FOP API
On 12.02.2006 21:18:56 Andreas L Delmelle wrote: On Feb 8, 2006, at 22:03, Simon Pepping wrote: Simon / Jeremias, 6. D5 (The FOUserAgent can return the FopFactory instance. (needed internally by FOP)): Why? Because FOUserAgent is the programmed way to get at configuration settings? Could it be better to implement get methods on the user agent which get the settings from the factory object (factory object not exposed)? Or even pass the factory object instead of the user agent (Cf. question 2)? I agree with this comment in particular. I'd prefer to not expose the Factory, but implement accessors for the persistent settings. It even allows for a sort of flexibility where it comes to the so-called persistent data across multiple rendering runs...? A bit unclear maybe, so some further explanation: I'm also thinking in terms of on-demand loading of certain data, if requested so by the user agent. Once it's loaded, it will be readily available for another user agent. If no user agent ever requests it, it will never be loaded into memory. Uhm, I can't follow you here. I understand that you prefer that all rendering-run-level and environment-level info is accessed directly by methods on the FOUserAgent, whereas I proposed to access the environment-level data only on the factory to have a clear distinction between the two levels. But: What data is loaded on-demand and requested by the user agent? If the factory would be exposed, and a lot of classes access it directly, the implied amount of checks whether certain features have already been loaded would be enormous. If this is centralized in the user agent, it becomes a lot easier to maintain. I don't see any of that. I decided that I will implement my proposal in a new branch. There, everyone can have a look at the real thing and we'll adjust as necessary to make everyone happy. You'll see that the whole thing is much less complicated than you might think. When everybody's happy, we can merge back or, in the worst case, discard the branch. Jeremias Maerki
Re: Finally finalizing the FOP API
On Feb 8, 2006, at 22:03, Simon Pepping wrote: Simon / Jeremias, 6. D5 (The FOUserAgent can return the FopFactory instance. (needed internally by FOP)): Why? Because FOUserAgent is the programmed way to get at configuration settings? Could it be better to implement get methods on the user agent which get the settings from the factory object (factory object not exposed)? Or even pass the factory object instead of the user agent (Cf. question 2)? I agree with this comment in particular. I'd prefer to not expose the Factory, but implement accessors for the persistent settings. It even allows for a sort of flexibility where it comes to the so-called persistent data across multiple rendering runs...? A bit unclear maybe, so some further explanation: I'm also thinking in terms of on-demand loading of certain data, if requested so by the user agent. Once it's loaded, it will be readily available for another user agent. If no user agent ever requests it, it will never be loaded into memory. If the factory would be exposed, and a lot of classes access it directly, the implied amount of checks whether certain features have already been loaded would be enormous. If this is centralized in the user agent, it becomes a lot easier to maintain. Cheers, Andreas
Re: Finally finalizing the FOP API
On 10.02.2006 18:39:15 Clay Leeds wrote: Looks good to me. I don't have much to add. I was wondering if the FOP API should include hooks to PostScript- style page-reference orientation information (or anything else PostScript-specific that may be missing). Is that something relevant to consider here? I don't think so. This is probably more about configuring the renderer which can be done directly. I'm currently more interested in finalizing the overall design of the top-level API. If later certain specialities are added it doesn't change the structure of the API. On Feb 10, 2006, at 7:43 AM, Jeremias Maerki wrote: I understand that some of you may not have a lot of time. I still hope to get some more feedback on this. I can give another task priority over this if anyone would like some more time to review. So, I'll probably start with work on PDF/A-1 support on Monday. So far I've incorporated the feedback from Jess and Simon. On 07.02.2006 10:09:38 Jeremias Maerki wrote: As part of my upcoming optimization work I want to finalize the FOP API. I've written down a proposal in the Wiki: http://wiki.apache.org/xmlgraphics-fop/ApiDesign If possible, I'd like to have that finished by the end of the week. Please post your feedback ASAP. Jeremias Maerki Thanks, Jeremias Maerki Clay Leeds [EMAIL PROTECTED] My religion is simple. My religion is kindness. -- HH Dalai Lama of Tibet Jeremias Maerki
Re: Finally finalizing the FOP API
I understand that some of you may not have a lot of time. I still hope to get some more feedback on this. I can give another task priority over this if anyone would like some more time to review. So, I'll probably start with work on PDF/A-1 support on Monday. So far I've incorporated the feedback from Jess and Simon. On 07.02.2006 10:09:38 Jeremias Maerki wrote: As part of my upcoming optimization work I want to finalize the FOP API. I've written down a proposal in the Wiki: http://wiki.apache.org/xmlgraphics-fop/ApiDesign If possible, I'd like to have that finished by the end of the week. Please post your feedback ASAP. Jeremias Maerki Thanks, Jeremias Maerki
Re: Finally finalizing the FOP API
Having just added reflection code to make my code work with 0.20.5 and 0.91 beta, I'd like to see the existing Fop() constructor continue to work as per 0.91 beta. Overall having to use reflection to maintain use of the current stable while being ready for the future is at once understandable and obnoxious. The simpler the new API is for simple cases (I'm *not* re-using anything from one execution to the next due to the infrequency of the calls, etc) and the sooner it stabilizes for these, the better. I had kind of assumed that beta meant API is stable for simple cases :-) -- Jess Holle Jeremias Maerki wrote: As part of my upcoming optimization work I want to finalize the FOP API. I've written down a proposal in the Wiki: http://wiki.apache.org/xmlgraphics-fop/ApiDesign If possible, I'd like to have that finished by the end of the week. Please post your feedback ASAP. Jeremias Maerki
Re: Finally finalizing the FOP API
Noted, but the fact that the API is not stable has been documented in [1]. We've been pushing finalizing the API before us for a long time. The old 0.20.5 API sadly doesn't fit all the requirements that we have today. Another idea for your situation is a wrapper API that shields you from the actualy API of the FO implementation you use. I've written such a wrapper API [2] although the published version is now a little behind and would need to be updated. Furthermore, I got negative feedback from Sun about my choice of name. But if there is sufficient demand and a little help I can always revive it. I'm actively using it in my private projects. [1] http://xmlgraphics.apache.org/fop/0.91/upgrading.html [2] http://www.jeremias-maerki.ch/dev/jaxg/index.html On 07.02.2006 10:46:48 Jess Holle wrote: Having just added reflection code to make my code work with 0.20.5 and 0.91 beta, I'd like to see the existing Fop() constructor continue to work as per 0.91 beta. Overall having to use reflection to maintain use of the current stable while being ready for the future is at once understandable and obnoxious. The simpler the new API is for simple cases (I'm *not* re-using anything from one execution to the next due to the infrequency of the calls, etc) and the sooner it stabilizes for these, the better. I had kind of assumed that beta meant API is stable for simple cases :-) -- Jess Holle Jeremias Maerki wrote: As part of my upcoming optimization work I want to finalize the FOP API. I've written down a proposal in the Wiki: http://wiki.apache.org/xmlgraphics-fop/ApiDesign If possible, I'd like to have that finished by the end of the week. Please post your feedback ASAP. Jeremias Maerki Jeremias Maerki
