Hi Pascal, I won't be merging this into anything other than trunk. Sorry, maybe I should have made that more explicit.
Mehdi On 2 July 2012 12:32, Pascal Sancho <[email protected]> wrote: > Hi, > > +1 for merging it to trunk. > > That said, I'm a little puzzled with the release process. > In my mind, a RC should come before a production release, freezing all > features. > Only bugfix should be permitted on RC. > Adding new feature to RC2 is a precedent that allows to add a new > feature after each RC, witch need to release a new... RC, etc. > I humbly suggest that the release process start with a 1.1 branch, > from witch RCx and final release will be tagged, that should allow to > continue merging branches onto trunk without any interaction on branch > release. > WDYT? > > 2012/7/2 Chris Bowditch <[email protected]>: > > 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 <[email protected] > >> <mailto:[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. > >> > >> > > > > > > > > -- > pascal >
