On 26/06/2012 15:39, mehdi houshmand wrote:
Sorry, added "[VOTE]" to subject line... My bad
+1 from me. Good work Mehdi and Pete. Chris
On 26 June 2012 15:38, mehdi houshmand <med1...@gmail.com <mailto:med1...@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.
