xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mehdi houshmand <med1...@gmail.com>
Subject Re: [VOTE] Merge Temp_URI_Unification
Date Mon, 02 Jul 2012 12:28:19 GMT
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 <psancho.asf@gmail.com> 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 <bowditch_chris@hotmail.com>:
> > 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 <med1985@gmail.com
> >> <mailto: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.
> >>
> >>
> >
> >
>
>
>
> --
> pascal
>

Mime
View raw message