+1
On Tue, Jun 26, 2012 at 3:39 PM, mehdi houshmand <[email protected]> wrote: > Sorry, added "[VOTE]" to subject line... My bad > > On 26 June 2012 15:38, mehdi houshmand <[email protected]> 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. > >
