xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hancock <peter.hanc...@gmail.com>
Subject Re: [VOTE] Merge Temp_URI_Unification
Date Mon, 02 Jul 2012 08:59:10 GMT
+1

On Tue, Jun 26, 2012 at 3:39 PM, mehdi houshmand <med1985@gmail.com> wrote:
> Sorry, added "[VOTE]" to subject line... My bad
>
> On 26 June 2012 15:38, mehdi houshmand <med1985@gmail.com> wrote:
>>
>> Hi All,
>>
>>
>>
>> I think we've got to the stage in the URI unification branch where it's
>> ready to be merged into trunk (not into 1.1RC1). I know there have been
>> proponents against the inclusion of this feature and/or those who are
>> concerned the wider implications as it means FOP has fewer contingency
>> methods when attempting file access. I'll try and explain how we've
>> addressed those concerns as well as some of the code improvements we've
>> made.
>>
>>
>>
>> - Syntactic URI fall-back mechanisms - if a URI is syntactically erroneous
>> i.e. contains white-space, "\" instead of "/", we do some validation on to
>> mitigate some of the common mistakes. However, we don't allow for falling
>> back to 'new File(".")' or "new URL(...).openStream()" since these can
>> obviously cause clashes in a highly parallelised multi-tenant environment.
>>
>>
>>
>> - Single FOP conf parse - Previously the renderer specific regions of the
>> FOP conf was being parsed on every run. This is costly to performance for
>> the obvious reason, but as well as this, it meant that font auto-detection
>> was having to be executed on every run. The font-caching was created to
>> mitigate some of those performance costs, however, caching the FOP conf
>> makes much more sense. It means we can get rid of the font-caching and don't
>> have to to worry about performance but it also allowed to do a lot of clean
>> up in the configuration packages. The renderer specific config is also lazy
>> loaded such that it is only parsed when the respective renderer is invoked,
>> mitigating the one-off cost of parsing that config.
>>
>>
>>
>> - The environment profile - We've created an environment profile that
>> abstracts the system in which FOP is invoked. This allows us to
>> programmatically enforce restrictions to, for example, font-caching and
>> auto-detection since users may want to control this behaviour for any number
>> of reasons.
>>
>>
>>
>> - Improved URI handling - because the URI resolution has been unified to a
>> couple of classes, the behaviour is much easier for users to understand.
>>
>>
>>
>> - Consistent base directories - We've tried to ensure that base
>> directories are consistent with FOP previously, the <base> and <font-base>
>> still work as previously.
>>
>>
>>
>> There are however some outstanding TODOs that need to be addressed,
>> however, though they are important, they don't need to be all merged in at
>> the same time. I will be working on these and keep the community updated:
>>
>>
>>
>> TODOs//
>>
>>
>>
>> - XGC and libraries - This is most likely the next project, we need to do
>> the same in the XGC project and look at some of FOPs dependencies (Batik
>> too!). The plan will be to move all the resource resolver classes to XGC
>> since that is the parent library so that they can be used though out the
>> XMLGraphics libraries.
>>
>>
>>
>> - Improved MIME type resolution - currently FOP's file-type
>> (file-MIME-type) is performed in-situ using file-name endings. This is,
>> while working perfectly fine on a desktop environment, would be less than
>> desirable if file-names were just hashes or the like from a virtual
>> file-system. We need to give the user the flexibility to define a file MIME
>> type without forcing them to put the file-ending in the URI.
>>
>> - Default handling in some of the Configurators - We have improved the
>> mechanism that handles default values in the configuration as well as config
>> injected via RendererOptions (on the FOUserAgent) and the FOP conf for PDF.
>> However, time constraints haven't allowed us to do the same for PS and AFP,
>> which would be nice to do. This isn't of utmost priority, but it would be
>> nice to not have the "if (x != null)" peppered around the source
>>
>> Sorry for the long email, I just thought it'd be a good time to expose
>> some of the work we've been doing,
>>
>> Mehdi
>>
>>
>> P.S. More information can be found wiki under the developers section, it's
>> currently down so I can't post a link.
>
>

Mime
View raw message