Ahh I see, ok, thanks Pascal. I think we got our wires crossed a little there ;)
Glenn, my plan was to merge the URI-resolution stuff in tomorrow. If this burdens you in some way, could you let me know how and maybe we can come to some resolution? As far as I can see, it shouldn't affect the 1.1rc1 branch at all. Mehdi On 2 July 2012 14:19, Pascal Sancho <[email protected]> wrote: > Sorry Mehdi, I realize that I started a new discussion. > Merging your development branch onto the trunk is not what puzzled me. > This has to be done as this. > > What I said is: currently there are concurrent enhancements and releases. > So, between the 1st RC and the final release there can be a lot of > differences, witch is not --from my point of view-- a good thing. > > IIRC, the 1.1 vote was for the 1.1RC1, not for the 1.1 branch witch > doesn't exist. > But I agree with you: it a such branch 1.1 should exist ;-) > > > 2012/7/2 mehdi houshmand <[email protected]>: > > Excuse my ignorance here, but why do any changes to trunk affect 1.1RC*? > The > > 1.1 branch has already been defined and voted upon, I don't see how any > > changes to trunk would affect it? I'm not very familiar with the FOPs > > releasing process so do excuse me. > > > > Mehdi > > > > > > On 2 July 2012 13:42, Pascal Sancho <[email protected]> wrote: > >> > >> Mehdi, > >> > >> I speak about post 1.1RC1. > >> Your merge will be against the trunk. > >> What about the 1.1RC2 or 1.1 final? > >> In the current usage, *all* FOP releases are tagged directly from > >> trunk (via a branch that is only to set FOP version and lib > >> dependencies). > >> So, every further RC or final releases are planed to be ma > >> 2012/7/2 mehdi houshmand <[email protected]>: > >> > 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 >
