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 <psancho....@gmail.com> 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 <med1...@gmail.com>:
> > 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 <psancho....@gmail.com> 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 <med1...@gmail.com>:
> >> > 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....@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_ch...@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 <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.
>
> --
> pascal
>

Reply via email to