[VOTE] Merge Temp_URI_Unification

[mehdi houshmand <me...@gmail.com>]

Sorry, added "[VOTE]" to subject line... My bad

On 26 June 2012 15:38, mehdi houshmand <me...@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.
>

Re: [VOTE] Merge Temp_URI_Unification

[Peter Hancock <pe...@gmail.com>]

+1

On Tue, Jun 26, 2012 at 3:39 PM, mehdi houshmand <me...@gmail.com> wrote:
> Sorry, added "[VOTE]" to subject line... My bad
>
> On 26 June 2012 15:38, mehdi houshmand <me...@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.
>
>

Re: [VOTE] Merge Temp_URI_Unification

[Glenn Adams <gl...@skynav.com>]

+1 but I'd prefer the merge wait a few days until I have completed the RC1
release

On Mon, Jul 2, 2012 at 6:28 AM, mehdi houshmand <me...@gmail.com> wrote:

> 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 <ps...@gmail.com> wrote:
>
>> Hi,
>>
>> +1 for merging it to trunk.
>>
>

Re: [VOTE] Merge Temp_URI_Unification

[Peter Hancock <pe...@gmail.com>]

Hi Vincent, FOP Dev,

On Wed, Jul 4, 2012 at 12:32 PM, Vincent Hennebert <vh...@gmail.com> wrote:
<snip/>
> And BTW, what is the recommended way to get a FopFactoryConfig? The
> javadoc of buildConfig doesn’t say. I think it should.
The need to obtain an instance of a FopFactoryConfig implementation is
most probably unnecessary, however we have made it an option for two
reasons:
 1 The unit test org.apache.fop.fotreetest.FOTreeTestCase uses
processing instructions in the parsed FO files to alter FopFactory
configuration.  We decided not to change this mechanism, and thus
required a way to modify the configuration.  By exposing the underling
FopFactoryConfig we were able to wrap the immutable instance in a
proxy that allows property modification.
 2 If an existing FOP client relies on the modification of the
FopFactory then there is a mechanism in place.

Modifying the FopFactory after construction is discouraged which is
why we have not advertised the practise in the javadocs or wiki.  I
have just noticed that the stativ method FopFactoryConfig
FopFactory.newInstance(FopFactoryConfig) is not marked as depricated -
I think the long term intention should be to make this method package
private, along with FopFactoryConfig.


>>> src/java/org/apache/fop/apps/io/TempResourceResolver
>>> • unless I’m mistaken there’s no way of releasing the temporary resource
>>>   once it’s no longer needed. The DefaultTempResourceResolver
>>>   implementation deleteOnExits the file but this may not be enough if
>>>   FOP is run on a server that is meant to (almost) never shut down. Or
>>>   did I miss something?
>>>
>>
>> You missed something; this is the default implementation. This is pretty
>> much only for the CLI use-case, if users wish to define their own
>> implementation, all they have to do is implement the interface.
>
> OK, so presuming I want to write my own implementation that does a more
> fine-grained management of resources, how do I know that I can release
> a given resource?

This is a good point.  Currently, FOP assumes that temporary resources
become unavailable for reading once the input stream is closed.  FOP
is expected to call InputStream.close(), and this call should be used
to trigger he release of the resource, perhaps by wrapping the
underlying InputStream in an implementation FilteredInputStream that
does this cleanup. We intend to document in detail some recipes for
implementing the ResourceResolver - there is currently some further
work required for the handling of resource types (we envision that
that these will consist of something like a superset of all MIME
types) that we wish to handle first.

Thanks,

Peter

Re: [VOTE] Merge Temp_URI_Unification

[Alexios Giotis <al...@gmail.com>]

> <snip/>
> Let me insist on that one. The inconsistency is actually introduced by
> Fop classes. Before the merge there were 14 classes having FOP in their
> names, vs 6 having Fop. Also, the product name is FOP, not Fop, and that
> should be reflected in the class names.
> 
> I still don't agree, it's not about the number of classes but rather the importance and location of those classes; FopFactory.java, Fop.java. If you feel very strongly about it, feel free to change it, I won't oppose it, but when someone thinks "wtf!!! Why are there so many different ways to write FOP!?!?!" and they do an svn blame, I don't want my name anywhere near it.

I agree with Mehdi. Besides the importance of the classes using Fop*, a quote from the Joshua's Bloch Effective Java, 2nd edition:

"Which class name would you rather see, HTTPURL or HttpUrl ? "


BTW, congratulations for this work, it will definitely help me.

Alexios Giotis

Re: [VOTE] Merge Temp_URI_Unification

[Craig Ringer <ri...@ringerc.id.au>]

On 07/05/2012 02:41 PM, mehdi houshmand wrote:
> Hi Chris/Glenn/Anyone else,
>
> You say command-line options should override the fop.xconf values, 
> which makes sense. But should not-given command-line options override 
> fop.xconf values too? Bare with me here, there is sense in the folly 
> of that sentence. Ok, so let's take the example above, with strict FO 
> validation, from the command line you have two options:
>
> 1) fop -r ... <other args>
>
> or
>
> 2) fop ... <other args>
>
> Obviously in option 1, you'd want strict FO validation to be invoked, 
> regardless of what's in the fop conf. But how do we treat option 2? 
> We're not explicitly telling it NOT to validate strictly, so how would 
> a user expect FOP to behave?

Unless an explicitly negating command-line option is specified, it 
should use the configuration. If you want a way to override a setting 
that's turned on in configuration, there needs to be a command-line 
syntax for negating options. Common ways programs do that are:

'n' prefix, eg:

   -nr

'+' for negation (ick!):

    fop +r

pre-fix negation argument that negates the next argument:

    fop -n -r
    fop '!' -r

case:

    fop -R

--
Craig Ringer

Re: [VOTE] Merge Temp_URI_Unification

[Clay Leeds <th...@gmail.com>]

Thanks! Happy Fourth (it's still the 4th even outside the U.S. ;-)!

Thanks for your efforts all!

"My religion is simple. My religion is kindness."
- HH The Dalai Lama of Tibet

On Jul 4, 2012, at 11:35 AM, mehdi houshmand <me...@gmail.com> wrote:

> I wouldn't worry Clay, I'm not sure I really know what this thread is about any more either. Either way, it's been merged but thanks for your support.
> 
> The fix of this regression is easy, I'll fix it in the morning.
> 
> On 4 July 2012 18:32, The Web Maestro <th...@gmail.com> wrote:
> I'm a bit confused... Am I correct that this [VOTE] relates to merging
> the Temp_URI_Unification to fop/trunk and not to FOP-1.1rc*? If so,
> then +1 and if not then +0 since I don't quite understand... (not
> blocker, but not enough info for me to +1... ;-)
> 
> Kind regards,
> 
> Clay Leeds
> --
> <th...@gmail.com> - <http://ourlil.com/>
> My religion is simple. My religion is kindness.
> - HH The 14th Dalai Lama of Tibet
> 
> 
> On Wed, Jul 4, 2012 at 9:26 AM, Chris Bowditch
> <bo...@hotmail.com> wrote:
> > On 04/07/2012 17:15, Glenn Adams wrote:
> >>
> >>
> >> On Wed, Jul 4, 2012 at 9:25 AM, mehdi houshmand <med1985@gmail.com
> >> <ma...@gmail.com>> wrote:
> >>
> >>     On 4 July 2012 12:32, Vincent Hennebert <vhennebert@gmail.com
> >>     <ma...@gmail.com>> wrote:
> >>
> >>
> >>         There does seem to be a regression. Before, the
> >>         FopFactoryConfigurator
> >>         object was getting the strict-validation element from the
> >>         config file
> >>         and calling FopFactory.setStrictValidation if it was set to
> >>         true. This
> >>         is no longer the case.
> >>
> >>         I’ve just tried to render a table with table-footer after
> >>         table-body,
> >>         and now a validation error is thrown even if I have
> >>         strict-validation
> >>         set to false in my config file. No validation error was thrown
> >>         before.
> >>
> >>
> >>     I've fixed the underlying issue but this is an interesting one; it
> >>     isn't obvious that settings from the fop conf override the
> >>     settings from the command line options. (Pete probably wrote this
> >>     part hahaha ;) )
> >>
> >>
> >> They shouldn't. Command line options should override the conf file.
> >>
> >
> > Agreed, but IIUC, the team just copied the existing functionality due to
> > time constraints. We should probably log a bug to track that as an issue.
> >
> > Thanks,
> >
> > Chris
> >
> >
> 

Re: [VOTE] Merge Temp_URI_Unification

[mehdi houshmand <me...@gmail.com>]

I wouldn't worry Clay, I'm not sure I really know what this thread is about
any more either. Either way, it's been merged but thanks for your support.

The fix of this regression is easy, I'll fix it in the morning.

On 4 July 2012 18:32, The Web Maestro <th...@gmail.com> wrote:

> I'm a bit confused... Am I correct that this [VOTE] relates to merging
> the Temp_URI_Unification to fop/trunk and not to FOP-1.1rc*? If so,
> then +1 and if not then +0 since I don't quite understand... (not
> blocker, but not enough info for me to +1... ;-)
>
> Kind regards,
>
> Clay Leeds
> --
> <th...@gmail.com> - <http://ourlil.com/>
> My religion is simple. My religion is kindness.
> - HH The 14th Dalai Lama of Tibet
>
>
> On Wed, Jul 4, 2012 at 9:26 AM, Chris Bowditch
> <bo...@hotmail.com> wrote:
> > On 04/07/2012 17:15, Glenn Adams wrote:
> >>
> >>
> >> On Wed, Jul 4, 2012 at 9:25 AM, mehdi houshmand <med1985@gmail.com
> >> <ma...@gmail.com>> wrote:
> >>
> >>     On 4 July 2012 12:32, Vincent Hennebert <vhennebert@gmail.com
> >>     <ma...@gmail.com>> wrote:
> >>
> >>
> >>         There does seem to be a regression. Before, the
> >>         FopFactoryConfigurator
> >>         object was getting the strict-validation element from the
> >>         config file
> >>         and calling FopFactory.setStrictValidation if it was set to
> >>         true. This
> >>         is no longer the case.
> >>
> >>         I’ve just tried to render a table with table-footer after
> >>         table-body,
> >>         and now a validation error is thrown even if I have
> >>         strict-validation
> >>         set to false in my config file. No validation error was thrown
> >>         before.
> >>
> >>
> >>     I've fixed the underlying issue but this is an interesting one; it
> >>     isn't obvious that settings from the fop conf override the
> >>     settings from the command line options. (Pete probably wrote this
> >>     part hahaha ;) )
> >>
> >>
> >> They shouldn't. Command line options should override the conf file.
> >>
> >
> > Agreed, but IIUC, the team just copied the existing functionality due to
> > time constraints. We should probably log a bug to track that as an issue.
> >
> > Thanks,
> >
> > Chris
> >
> >
>

Re: [VOTE] Merge Temp_URI_Unification

[The Web Maestro <th...@gmail.com>]

I'm a bit confused... Am I correct that this [VOTE] relates to merging
the Temp_URI_Unification to fop/trunk and not to FOP-1.1rc*? If so,
then +1 and if not then +0 since I don't quite understand... (not
blocker, but not enough info for me to +1... ;-)

Kind regards,

Clay Leeds
--
<th...@gmail.com> - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet


On Wed, Jul 4, 2012 at 9:26 AM, Chris Bowditch
<bo...@hotmail.com> wrote:
> On 04/07/2012 17:15, Glenn Adams wrote:
>>
>>
>> On Wed, Jul 4, 2012 at 9:25 AM, mehdi houshmand <med1985@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>>     On 4 July 2012 12:32, Vincent Hennebert <vhennebert@gmail.com
>>     <ma...@gmail.com>> wrote:
>>
>>
>>         There does seem to be a regression. Before, the
>>         FopFactoryConfigurator
>>         object was getting the strict-validation element from the
>>         config file
>>         and calling FopFactory.setStrictValidation if it was set to
>>         true. This
>>         is no longer the case.
>>
>>         I’ve just tried to render a table with table-footer after
>>         table-body,
>>         and now a validation error is thrown even if I have
>>         strict-validation
>>         set to false in my config file. No validation error was thrown
>>         before.
>>
>>
>>     I've fixed the underlying issue but this is an interesting one; it
>>     isn't obvious that settings from the fop conf override the
>>     settings from the command line options. (Pete probably wrote this
>>     part hahaha ;) )
>>
>>
>> They shouldn't. Command line options should override the conf file.
>>
>
> Agreed, but IIUC, the team just copied the existing functionality due to
> time constraints. We should probably log a bug to track that as an issue.
>
> Thanks,
>
> Chris
>
>

Re: [VOTE] Merge Temp_URI_Unification

[mehdi houshmand <me...@gmail.com>]

Ok, so I've made the CLI options override when set, and not override when
not set. I think that CommandLineOption class needs a little TLC, we can
use Commons CLI or some such library (
http://java-source.net/open-source/command-line). No point reinventing the
wheel.

On 5 July 2012 08:27, Glenn Adams <gl...@skynav.com> wrote:

>
> On Thu, Jul 5, 2012 at 12:41 AM, mehdi houshmand <me...@gmail.com>wrote:
>
>> Hi Chris/Glenn/Anyone else,
>>
>> You say command-line options should override the fop.xconf values, which
>> makes sense. But should not-given command-line options override fop.xconf
>> values too? Bare with me here, there is sense in the folly of that
>> sentence. Ok, so let's take the example above, with strict FO validation,
>> from the command line you have two options:
>>
>> 1) fop -r ... <other args>
>>
>> or
>>
>> 2) fop ... <other args>
>>
>> Obviously in option 1, you'd want strict FO validation to be invoked,
>> regardless of what's in the fop conf. But how do we treat option 2? We're
>> not explicitly telling it NOT to validate strictly, so how would a user
>> expect FOP to behave?
>>
>
> In the case of strict validation, if either configuration file or command
> line option says do strict validation, then strict validation should apply.
> We would need an option "don't do strict validation" in order to allow the
> command line to override a configuration file saying to perform strict
> validation.
>
>

Re: [VOTE] Merge Temp_URI_Unification

[Glenn Adams <gl...@skynav.com>]

On Thu, Jul 5, 2012 at 12:41 AM, mehdi houshmand <me...@gmail.com> wrote:

> Hi Chris/Glenn/Anyone else,
>
> You say command-line options should override the fop.xconf values, which
> makes sense. But should not-given command-line options override fop.xconf
> values too? Bare with me here, there is sense in the folly of that
> sentence. Ok, so let's take the example above, with strict FO validation,
> from the command line you have two options:
>
> 1) fop -r ... <other args>
>
> or
>
> 2) fop ... <other args>
>
> Obviously in option 1, you'd want strict FO validation to be invoked,
> regardless of what's in the fop conf. But how do we treat option 2? We're
> not explicitly telling it NOT to validate strictly, so how would a user
> expect FOP to behave?
>

In the case of strict validation, if either configuration file or command
line option says do strict validation, then strict validation should apply.
We would need an option "don't do strict validation" in order to allow the
command line to override a configuration file saying to perform strict
validation.

Re: [VOTE] Merge Temp_URI_Unification

[mehdi houshmand <me...@gmail.com>]

Hi Chris/Glenn/Anyone else,

You say command-line options should override the fop.xconf values, which
makes sense. But should not-given command-line options override fop.xconf
values too? Bare with me here, there is sense in the folly of that
sentence. Ok, so let's take the example above, with strict FO validation,
from the command line you have two options:

1) fop -r ... <other args>

or

2) fop ... <other args>

Obviously in option 1, you'd want strict FO validation to be invoked,
regardless of what's in the fop conf. But how do we treat option 2? We're
not explicitly telling it NOT to validate strictly, so how would a user
expect FOP to behave?

On 4 July 2012 17:26, Chris Bowditch <bo...@hotmail.com> wrote:

> On 04/07/2012 17:15, Glenn Adams wrote:
>
>>
>> On Wed, Jul 4, 2012 at 9:25 AM, mehdi houshmand <med1985@gmail.com<mailto:
>> med1985@gmail.com>> wrote:
>>
>>     On 4 July 2012 12:32, Vincent Hennebert <vhennebert@gmail.com
>>     <ma...@gmail.com>> wrote:
>>
>>
>>         There does seem to be a regression. Before, the
>>         FopFactoryConfigurator
>>         object was getting the strict-validation element from the
>>         config file
>>         and calling FopFactory.setStrictValidation if it was set to
>>         true. This
>>         is no longer the case.
>>
>>         I’ve just tried to render a table with table-footer after
>>         table-body,
>>         and now a validation error is thrown even if I have
>>         strict-validation
>>         set to false in my config file. No validation error was thrown
>>         before.
>>
>>
>>     I've fixed the underlying issue but this is an interesting one; it
>>     isn't obvious that settings from the fop conf override the
>>     settings from the command line options. (Pete probably wrote this
>>     part hahaha ;) )
>>
>>
>> They shouldn't. Command line options should override the conf file.
>>
>>
> Agreed, but IIUC, the team just copied the existing functionality due to
> time constraints. We should probably log a bug to track that as an issue.
>
> Thanks,
>
> Chris
>
>
>

Re: [VOTE] Merge Temp_URI_Unification

[Chris Bowditch <bo...@hotmail.com>]

On 04/07/2012 17:15, Glenn Adams wrote:
>
> On Wed, Jul 4, 2012 at 9:25 AM, mehdi houshmand <med1985@gmail.com 
> <ma...@gmail.com>> wrote:
>
>     On 4 July 2012 12:32, Vincent Hennebert <vhennebert@gmail.com
>     <ma...@gmail.com>> wrote:
>
>
>         There does seem to be a regression. Before, the
>         FopFactoryConfigurator
>         object was getting the strict-validation element from the
>         config file
>         and calling FopFactory.setStrictValidation if it was set to
>         true. This
>         is no longer the case.
>
>         I’ve just tried to render a table with table-footer after
>         table-body,
>         and now a validation error is thrown even if I have
>         strict-validation
>         set to false in my config file. No validation error was thrown
>         before.
>
>
>     I've fixed the underlying issue but this is an interesting one; it
>     isn't obvious that settings from the fop conf override the
>     settings from the command line options. (Pete probably wrote this
>     part hahaha ;) )
>
>
> They shouldn't. Command line options should override the conf file.
>

Agreed, but IIUC, the team just copied the existing functionality due to 
time constraints. We should probably log a bug to track that as an issue.

Thanks,

Chris

Re: [VOTE] Merge Temp_URI_Unification

[Glenn Adams <gl...@skynav.com>]

On Wed, Jul 4, 2012 at 9:25 AM, mehdi houshmand <me...@gmail.com> wrote:

> On 4 July 2012 12:32, Vincent Hennebert <vh...@gmail.com> wrote:
>
>>
>> There does seem to be a regression. Before, the FopFactoryConfigurator
>> object was getting the strict-validation element from the config file
>> and calling FopFactory.setStrictValidation if it was set to true. This
>> is no longer the case.
>>
>> I’ve just tried to render a table with table-footer after table-body,
>> and now a validation error is thrown even if I have strict-validation
>> set to false in my config file. No validation error was thrown before.
>>
>
> I've fixed the underlying issue but this is an interesting one; it isn't
> obvious that settings from the fop conf override the settings from the
> command line options. (Pete probably wrote this part hahaha ;) )
>

They shouldn't. Command line options should override the conf file.

Re: [VOTE] Merge Temp_URI_Unification

[mehdi houshmand <me...@gmail.com>]

On 4 July 2012 12:32, Vincent Hennebert <vh...@gmail.com> wrote:

> One thing I forgot to mention: this work deserves its entry in the
> status.xml file, with importance set to ‘high’.
> <snip/>
> Let me insist on that one. The inconsistency is actually introduced by
> Fop classes. Before the merge there were 14 classes having FOP in their
> names, vs 6 having Fop. Also, the product name is FOP, not Fop, and that
> should be reflected in the class names.
>

I still don't agree, it's not about the number of classes but rather the
importance and location of those classes; FopFactory.java, Fop.java. If you
feel very strongly about it, feel free to change it, I won't oppose it, but
when someone thinks "wtf!!! Why are there so many different ways to write
FOP!?!?!" and they do an svn blame, I don't want my name anywhere near it.

<snip/>
> I’m confused. It seems that I can call that method with an
> ‘application/pdf’ mimeType and a PSRendererConfigParser instance. In
> which case the parser would not be able to parse PDF-specific options,
> and would silently ignore them. Or did I miss something?
>

You missed something. For most the configurators, you are correct, but for
the Bitmap configurators it gets a little bit more involved, they re-use
the same code. It was a choice between either a) duplicating code, or b)
doing what we did. (There was a c) option, but as always, it involved a lot
more redesign than we had time for.)


> <snip/>
> There does seem to be a regression. Before, the FopFactoryConfigurator
> object was getting the strict-validation element from the config file
> and calling FopFactory.setStrictValidation if it was set to true. This
> is no longer the case.
>
> I’ve just tried to render a table with table-footer after table-body,
> and now a validation error is thrown even if I have strict-validation
> set to false in my config file. No validation error was thrown before.
>

I've fixed the underlying issue but this is an interesting one; it isn't
obvious that settings from the fop conf override the settings from the
command line options. (Pete probably wrote this part hahaha ;) )


> So when you remove it you will have to re-write the build method such
> that it doesn’t call buildConfig anymore. How will you do? (Admittedly
> I haven’t studied the new API in much detail.)
>
> And BTW, what is the recommended way to get a FopFactoryConfig? The
> javadoc of buildConfig doesn’t say. I think it should.


The client doesn't need access to the FopFactoryConfig object, it's a
wrapper for all the configuration objects that FOP uses. You instantiate a
FopFactory by using the FopFactoryBuilder.build(). I was going to write up
documentation suggesting as much, but I haven't had the chance to do so yet.


> I’m not sure I understand. How is that supposed to help? Wouldn’t it
> actually be more helpful if the FopFactory were now referring to the
> interface? That would indicate to users that something is going to
> change and they should take the habit of looking at FopFactoryConfig
> from now on.


I think the thought process was that users would be more used to accessing
those members via the FopFactory so linking back to that same object would
be more explicit. Maybe it doesn't make sense to anyone other than me/Pete.

>> src/java/org/apache/fop/apps/io/InternalResourceResolver
> Why is it a public class then if it’s supposed to be internal to FOP?
> IIC that apps/io package is meant to become part of the public API?
>

Well Java doesn't have a project only access modifier so... Where else
would we put it? This class is peculates through FOP so it has to be public.


> >> • getBaseURI: I don’t think adding a slash at the end of the URI if
> >> it’s
> >>   not there is desirable, because that effectively changes the base URI.
> >>   That may lead to very confusing errors.
> >>
> >
> > As the javadoc suggests this is for giving you a directory base URI, I've
> > changed the method signature to {getBaseURI, getBaseDirectoryURI}.
>
> Ah, I’m glad to hear that I was right to assume that the getBaseURI
> method returns a base URI :-)
>
> What I’m talking about is that, by adding a final ‘/’ to the given
> string, you are effectively changing the base URI.


> For example, that method is called by the AFPResourceAccessor class,
> which passes as a parameter the baseURI it’s been given, which that
> getBaseURI method may change into a different base URI! This is very
> misleading and may result into hard-to-find errors.
>

The behaviour is the same as it was previously. I wanted to have a single
base URI for ALL of FOPs URI resolution, but that would be devastating to
backwards compatibility. Don't hate the player, hate the game ;)


> >> src/java/org/apache/fop/apps/io/TempResourceResolver
>

>
> You missed something; this is the default implementation. This is pretty
> > much only for the CLI use-case, if users wish to define their own
> > implementation, all they have to do is implement the interface.
>
> OK, so presuming I want to write my own implementation that does a more
> fine-grained management of resources, how do I know that I can release
> a given resource?
>

Uhmm... I dunno. I didn't really handle this part of the code, Pete?
Presumably, since you have only read OR write access, you can delete it
once it's written, but you'll have to check with Pete.

Re: [VOTE] Merge Temp_URI_Unification

[Vincent Hennebert <vh...@gmail.com>]

One thing I forgot to mention: this work deserves its entry in the
status.xml file, with importance set to ‘high’.


On 04/07/12 08:38, mehdi houshmand wrote:
> On 3 July 2012 15:48, Vincent Hennebert wrote:
<snip/>
>> The new classes FopConfParser, FopFactoryBuilder and FopFactoryConfig
>> should be renamed into FOPConfParser, FOPFactoryBuilder and
>> FOPFactoryConfig. The fact that some existing public classes have Fop in
>> lower case in their names was a mistake that was discovered after the
>> API was frozen. Let’s not do that mistake again.
>>
> 
> I don't agree, I think this makes the classes more inconsistent rather than
> less so. I don't particularly have an opinion whether they should be Fop*
> or FOP* but I think either way, there should be consistency

Let me insist on that one. The inconsistency is actually introduced by
Fop classes. Before the merge there were 14 classes having FOP in their
names, vs 6 having Fop. Also, the product name is FOP, not Fop, and that
should be reflected in the class names.


<snip/>
> • getRendererConfig(String mimeType, RendererConfigParser configCreator)
>>   isn’t there a risk of mismatch between the given mimeType and
>>   configCreator? Can’t the mimeType be taken from the
>>   RendererConfigParser.getMimeType method?
>>
> 
> No. The same parser can be used for more than one MIME type and we don't
> want the config data to be retrieved from the wrong MIME type.

I’m confused. It seems that I can call that method with an
‘application/pdf’ mimeType and a PSRendererConfigParser instance. In
which case the parser would not be able to parse PDF-specific options,
and would silently ignore them. Or did I miss something?


<snip/>
>> • getHyphPatNames()
>>   this is hard to pronounce; also ‘Pat’ can easily be mistaken for
>>   ‘Path’
>>   s/getHyphPatNames/getHyphenationPatternNames/?
>>
> 
> Luckily it's written so you don't have to pronounce it ;). No seriously,
> done.

Thanks, my brain’s internal read aloud feature was stumbling upon that
one :-)


>> src/java/org/apache/fop/apps/FopConfParser.java
>> • there’s a mistake in the handling of ‘strict-validation’: this is
>>   related to checking the conformance of XSL-FO documents against the
>>   spec. The setting to strictly check the validity of config files is
>>   ‘strict-configuration’
>>
> 
> Again, there's a TODO, I don't think this is a regression but just
> something that was confused previously, though again, time constraints...

There does seem to be a regression. Before, the FopFactoryConfigurator
object was getting the strict-validation element from the config file
and calling FopFactory.setStrictValidation if it was set to true. This
is no longer the case.

I’ve just tried to render a table with table-footer after table-body,
and now a validation error is thrown even if I have strict-validation
set to false in my config file. No validation error was thrown before.


>> src/java/org/apache/fop/apps/FopFactoryBuilder.java
>> • the buildConfig method is deprecated but is used by the build method
>>   underneath, which is itself not deprecated. But then it shouldn’t rely
>>   on a deprecated method?
>>
> 
> The javadoc makes it clear that the only reason this is there is to
> maintain backwards compatibility, we'll remove it at some point in the
> future when users are more comfortable with the new API design.

So when you remove it you will have to re-write the build method such
that it doesn’t call buildConfig anymore. How will you do? (Admittedly
I haven’t studied the new API in much detail.)

And BTW, what is the recommended way to get a FopFactoryConfig? The
javadoc of buildConfig doesn’t say. I think it should.


>> src/java/org/apache/fop/apps/FopFactoryConfig.java
>> • This is an interface whose methods’ javadocs refer to the FopFactory
>>   concrete class. So an abstraction depends on a concrete
>>   implementation. Surely that should be the other way around?
>>
> 
> Again, this is to make the transition easier for users. Users are used to
> accessing these members via the FopFactory and the javadocs help lubricate
> the transition.

I’m not sure I understand. How is that supposed to help? Wouldn’t it
actually be more helpful if the FopFactory were now referring to the
interface? That would indicate to users that something is going to
change and they should take the habit of looking at FopFactoryConfig
from now on.


>> src/java/org/apache/fop/apps/io/InternalResourceResolver
>> • what does ‘Internal’ stand for?
>>
> 
> Stand for? It doesn't stand for anything. This class is FOPs internal
> resource resolver that does some primitive URI validation when strings are
> given and holds the base URI when relative URIs are given.

Why is it a public class then if it’s supposed to be internal to FOP?
IIC that apps/io package is meant to become part of the public API?


>> • getBaseURI: I don’t think adding a slash at the end of the URI if 
>> it’s
>>   not there is desirable, because that effectively changes the base URI.
>>   That may lead to very confusing errors.
>>
> 
> As the javadoc suggests this is for giving you a directory base URI, I've
> changed the method signature to {getBaseURI, getBaseDirectoryURI}.

Ah, I’m glad to hear that I was right to assume that the getBaseURI
method returns a base URI :-)

What I’m talking about is that, by adding a final ‘/’ to the given
string, you are effectively changing the base URI.

For example, that method is called by the AFPResourceAccessor class,
which passes as a parameter the baseURI it’s been given, which that
getBaseURI method may change into a different base URI! This is very
misleading and may result into hard-to-find errors.


>> src/java/org/apache/fop/apps/io/TempResourceResolver
>> • unless I’m mistaken there’s no way of releasing the temporary resource
>>   once it’s no longer needed. The DefaultTempResourceResolver
>>   implementation deleteOnExits the file but this may not be enough if
>>   FOP is run on a server that is meant to (almost) never shut down. Or
>>   did I miss something?
>>
> 
> You missed something; this is the default implementation. This is pretty
> much only for the CLI use-case, if users wish to define their own
> implementation, all they have to do is implement the interface.

OK, so presuming I want to write my own implementation that does a more
fine-grained management of resources, how do I know that I can release
a given resource?


<snip/>


Vincent

Re: [VOTE] Merge Temp_URI_Unification

[mehdi houshmand <me...@gmail.com>]

Just a few amendments:

- File.createTempFile(...) failed the unit tests and I didn't have time to
investigate why, this could be done in the future, though I'm not sure the
pros/cons of doing so.

- The method signature change getBaseURI -> getBaseDirectoryURI wasn't
done. After speaking to PH, it didn't seem appropriate to refer to it as a
directory since it could be anything. The javadoc clearly describes the
behaviour of the method, I think this is sufficient for now.

On 4 July 2012 08:38, mehdi houshmand <me...@gmail.com> wrote:

>
>
> On 3 July 2012 15:48, Vincent Hennebert <vh...@gmail.com> wrote:
>
>> I had started to build up a list of questions and comments but didn’t
>> get round to finishing it in time. Anyway, here it is, hopefully it will
>> still provide valuable feedback. The most important items to address are
>> the possible regression regarding strict FO validation and the public
>> API.
>>
>> The new classes FopConfParser, FopFactoryBuilder and FopFactoryConfig
>> should be renamed into FOPConfParser, FOPFactoryBuilder and
>> FOPFactoryConfig. The fact that some existing public classes have Fop in
>> lower case in their names was a mistake that was discovered after the
>> API was frozen. Let’s not do that mistake again.
>>
>
> I don't agree, I think this makes the classes more inconsistent rather
> than less so. I don't particularly have an opinion whether they should be
> Fop* or FOP* but I think either way, there should be consistency
>
>
>>
>> There are quite a few typos in the javadocs of the new class, it would
>> be good to fix them.
>>
>> src/java/org/apache/fop/apps/EnvironmentProfile.java
>> • class javadoc: “The environment profile represents the restrictions
>>   and allowances that FOP is”... what?
>>
>
> Done.
>
>
>>
>> src/java/org/apache/fop/apps/EnvironmentalProfileFactory.java
>> • should be renamed into EnvironmentProfileFactory
>> • in the inner Profile class: there are checks that constructor
>>   parameters are not null, except for FontManager. So may that be null
>>   then? Doesn’t look like.
>>
>
> Done.
>
>
>>
>> src/java/org/apache/fop/apps/FOUserAgent.java
>> • left-over TODO in resolveURI: should that be left as-is for now?
>>
>
> Yes. There are XGC classes that require this, there's already a TODO there
> suggesting that we intend on removing this.
>
> • getRendererConfig(String mimeType, RendererConfigParser configCreator)
>>   isn’t there a risk of mismatch between the given mimeType and
>>   configCreator? Can’t the mimeType be taken from the
>>   RendererConfigParser.getMimeType method?
>>
>
> No. The same parser can be used for more than one MIME type and we don't
> want the config data to be retrieved from the wrong MIME type.
>
>
>> • getRendererConfiguration(String mimeType)
>>   This comment:
>>   // silently pass over configurations without mime type
>>   Really? Don’t we want to at least display a warning?
>>
>
> This code is copy/pasted from elsewhere, we could have fixed this, but
> we'd also have to test it. Time constraints didn't allow such luxuries.
>
>
>> • public ColorSpaceCache getColorSpaceCache() {
>>   /** TODO: javadoc*/
>>
>
> Done
>
>
>> • getHyphPatNames()
>>   this is hard to pronounce; also ‘Pat’ can easily be mistaken for
>>   ‘Path’
>>   s/getHyphPatNames/getHyphenationPatternNames/?
>>
>
> Luckily it's written so you don't have to pronounce it ;). No seriously,
> done.
>
>
>>
>> src/java/org/apache/fop/apps/FopConfParser.java
>> • there’s a mistake in the handling of ‘strict-validation’: this is
>>   related to checking the conformance of XSL-FO documents against the
>>   spec. The setting to strictly check the validity of config files is
>>   ‘strict-configuration’
>>
>
> Again, there's a TODO, I don't think this is a regression but just
> something that was confused previously, though again, time constraints...
>
>
>>
>> src/java/org/apache/fop/apps/FopFactoryBuilder.java
>> • the buildConfig method is deprecated but is used by the build method
>>   underneath, which is itself not deprecated. But then it shouldn’t rely
>>   on a deprecated method?
>>
>
> The javadoc makes it clear that the only reason this is there is to
> maintain backwards compatibility, we'll remove it at some point in the
> future when users are more comfortable with the new API design.
>
>
>>
>> src/java/org/apache/fop/apps/FopFactoryConfig.java
>> • This is an interface whose methods’ javadocs refer to the FopFactory
>>   concrete class. So an abstraction depends on a concrete
>>   implementation. Surely that should be the other way around?
>>
>
> Again, this is to make the transition easier for users. Users are used to
> accessing these members via the FopFactory and the javadocs help lubricate
> the transition.
>
>
>>
>> src/java/org/apache/fop/apps/io/InternalResourceResolver
>> • what does ‘Internal’ stand for?
>>
>
> Stand for? It doesn't stand for anything. This class is FOPs internal
> resource resolver that does some primitive URI validation when strings are
> given and holds the base URI when relative URIs are given.
>
>
>> • getBaseURI: I don’t think adding a slash at the end of the URI if it’s
>>   not there is desirable, because that effectively changes the base URI.
>>   That may lead to very confusing errors.
>>
>
> As the javadoc suggests this is for giving you a directory base URI, I've
> changed the method signature to {getBaseURI, getBaseDirectoryURI}.
>
>
>>
>> src/java/org/apache/fop/apps/io/TempResourceResolver
>> • unless I’m mistaken there’s no way of releasing the temporary resource
>>   once it’s no longer needed. The DefaultTempResourceResolver
>>   implementation deleteOnExits the file but this may not be enough if
>>   FOP is run on a server that is meant to (almost) never shut down. Or
>>   did I miss something?
>>
>
> You missed something; this is the default implementation. This is pretty
> much only for the CLI use-case, if users wish to define their own
> implementation, all they have to do is implement the interface.
>
>
>> • in DefaultTempResourceResolver.getTempFile: the File.createTempFile
>>   method should be used instead of querying the ‘java.io.tmpdir’
>>   property.
>>
>
> Done.
>
>
>>
>> src/java/org/apache/fop/fonts/FontConfig.java
>> • all this interface declares is an inner FontConfigParser interface.
>>   Why not simply promote FontConfigParser as a top-level interface and
>>   remove FontConfig?
>>
>
> The intention was to provide an interface that covers both use cases, AFP
> and everything else, so that we could make the font configuration process a
> bit more OOP and a bit less "if (something) do something". Time constraints
> howerver...
>
>
>>
>> src/java/org/apache/fop/fonts/FontConfigurator.java
>> • some documentation about the T generic parameter would be good. Also,
>>   shouldn’t this parameter be bounded by some interface?
>>
>
> See the reply above. Again, there's a TODO suggesting just that, again,
> time constraints...
>
>
>>
>> Thanks,
>> Vincent
>>
>>
>> On 03/07/12 10:35, mehdi houshmand wrote:
>> > Thanks guys, that's 5 x +1 and no one in opposition. I'll merge in the
>> > branch imminently and update the docs as appropriate
>> >
>> > On 2 July 2012 14:40, Glenn Adams <gl...@skynav.com> wrote:
>> >
>> >>
>> >> On Mon, Jul 2, 2012 at 7:25 AM, mehdi houshmand <me...@gmail.com>
>> wrote:
>> >>
>> >>> 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.
>> >>>
>> >>
>> >> Go ahead. I'm going to rename the fop_1.1rc1 branch to fop_1.1 and then
>> >> create a fop_1.1rc1 tag on that branch that corresponds with the
>> current
>> >> rc1 rev.
>> >>
>> >
>>
>>
>

Re: [VOTE] Merge Temp_URI_Unification

[mehdi houshmand <me...@gmail.com>]

On 3 July 2012 15:48, Vincent Hennebert <vh...@gmail.com> wrote:

> I had started to build up a list of questions and comments but didn’t
> get round to finishing it in time. Anyway, here it is, hopefully it will
> still provide valuable feedback. The most important items to address are
> the possible regression regarding strict FO validation and the public
> API.
>
> The new classes FopConfParser, FopFactoryBuilder and FopFactoryConfig
> should be renamed into FOPConfParser, FOPFactoryBuilder and
> FOPFactoryConfig. The fact that some existing public classes have Fop in
> lower case in their names was a mistake that was discovered after the
> API was frozen. Let’s not do that mistake again.
>

I don't agree, I think this makes the classes more inconsistent rather than
less so. I don't particularly have an opinion whether they should be Fop*
or FOP* but I think either way, there should be consistency


>
> There are quite a few typos in the javadocs of the new class, it would
> be good to fix them.
>
> src/java/org/apache/fop/apps/EnvironmentProfile.java
> • class javadoc: “The environment profile represents the restrictions
>   and allowances that FOP is”... what?
>

Done.


>
> src/java/org/apache/fop/apps/EnvironmentalProfileFactory.java
> • should be renamed into EnvironmentProfileFactory
> • in the inner Profile class: there are checks that constructor
>   parameters are not null, except for FontManager. So may that be null
>   then? Doesn’t look like.
>

Done.


>
> src/java/org/apache/fop/apps/FOUserAgent.java
> • left-over TODO in resolveURI: should that be left as-is for now?
>

Yes. There are XGC classes that require this, there's already a TODO there
suggesting that we intend on removing this.

• getRendererConfig(String mimeType, RendererConfigParser configCreator)
>   isn’t there a risk of mismatch between the given mimeType and
>   configCreator? Can’t the mimeType be taken from the
>   RendererConfigParser.getMimeType method?
>

No. The same parser can be used for more than one MIME type and we don't
want the config data to be retrieved from the wrong MIME type.


> • getRendererConfiguration(String mimeType)
>   This comment:
>   // silently pass over configurations without mime type
>   Really? Don’t we want to at least display a warning?
>

This code is copy/pasted from elsewhere, we could have fixed this, but we'd
also have to test it. Time constraints didn't allow such luxuries.


> • public ColorSpaceCache getColorSpaceCache() {
>   /** TODO: javadoc*/
>

Done


> • getHyphPatNames()
>   this is hard to pronounce; also ‘Pat’ can easily be mistaken for
>   ‘Path’
>   s/getHyphPatNames/getHyphenationPatternNames/?
>

Luckily it's written so you don't have to pronounce it ;). No seriously,
done.


>
> src/java/org/apache/fop/apps/FopConfParser.java
> • there’s a mistake in the handling of ‘strict-validation’: this is
>   related to checking the conformance of XSL-FO documents against the
>   spec. The setting to strictly check the validity of config files is
>   ‘strict-configuration’
>

Again, there's a TODO, I don't think this is a regression but just
something that was confused previously, though again, time constraints...


>
> src/java/org/apache/fop/apps/FopFactoryBuilder.java
> • the buildConfig method is deprecated but is used by the build method
>   underneath, which is itself not deprecated. But then it shouldn’t rely
>   on a deprecated method?
>

The javadoc makes it clear that the only reason this is there is to
maintain backwards compatibility, we'll remove it at some point in the
future when users are more comfortable with the new API design.


>
> src/java/org/apache/fop/apps/FopFactoryConfig.java
> • This is an interface whose methods’ javadocs refer to the FopFactory
>   concrete class. So an abstraction depends on a concrete
>   implementation. Surely that should be the other way around?
>

Again, this is to make the transition easier for users. Users are used to
accessing these members via the FopFactory and the javadocs help lubricate
the transition.


>
> src/java/org/apache/fop/apps/io/InternalResourceResolver
> • what does ‘Internal’ stand for?
>

Stand for? It doesn't stand for anything. This class is FOPs internal
resource resolver that does some primitive URI validation when strings are
given and holds the base URI when relative URIs are given.


> • getBaseURI: I don’t think adding a slash at the end of the URI if it’s
>   not there is desirable, because that effectively changes the base URI.
>   That may lead to very confusing errors.
>

As the javadoc suggests this is for giving you a directory base URI, I've
changed the method signature to {getBaseURI, getBaseDirectoryURI}.


>
> src/java/org/apache/fop/apps/io/TempResourceResolver
> • unless I’m mistaken there’s no way of releasing the temporary resource
>   once it’s no longer needed. The DefaultTempResourceResolver
>   implementation deleteOnExits the file but this may not be enough if
>   FOP is run on a server that is meant to (almost) never shut down. Or
>   did I miss something?
>

You missed something; this is the default implementation. This is pretty
much only for the CLI use-case, if users wish to define their own
implementation, all they have to do is implement the interface.


> • in DefaultTempResourceResolver.getTempFile: the File.createTempFile
>   method should be used instead of querying the ‘java.io.tmpdir’
>   property.
>

Done.


>
> src/java/org/apache/fop/fonts/FontConfig.java
> • all this interface declares is an inner FontConfigParser interface.
>   Why not simply promote FontConfigParser as a top-level interface and
>   remove FontConfig?
>

The intention was to provide an interface that covers both use cases, AFP
and everything else, so that we could make the font configuration process a
bit more OOP and a bit less "if (something) do something". Time constraints
howerver...


>
> src/java/org/apache/fop/fonts/FontConfigurator.java
> • some documentation about the T generic parameter would be good. Also,
>   shouldn’t this parameter be bounded by some interface?
>

See the reply above. Again, there's a TODO suggesting just that, again,
time constraints...


>
> Thanks,
> Vincent
>
>
> On 03/07/12 10:35, mehdi houshmand wrote:
> > Thanks guys, that's 5 x +1 and no one in opposition. I'll merge in the
> > branch imminently and update the docs as appropriate
> >
> > On 2 July 2012 14:40, Glenn Adams <gl...@skynav.com> wrote:
> >
> >>
> >> On Mon, Jul 2, 2012 at 7:25 AM, mehdi houshmand <me...@gmail.com>
> wrote:
> >>
> >>> 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.
> >>>
> >>
> >> Go ahead. I'm going to rename the fop_1.1rc1 branch to fop_1.1 and then
> >> create a fop_1.1rc1 tag on that branch that corresponds with the current
> >> rc1 rev.
> >>
> >
>
>

Re: [VOTE] Merge Temp_URI_Unification

[Vincent Hennebert <vh...@gmail.com>]

I had started to build up a list of questions and comments but didn’t
get round to finishing it in time. Anyway, here it is, hopefully it will
still provide valuable feedback. The most important items to address are
the possible regression regarding strict FO validation and the public
API.

The new classes FopConfParser, FopFactoryBuilder and FopFactoryConfig
should be renamed into FOPConfParser, FOPFactoryBuilder and
FOPFactoryConfig. The fact that some existing public classes have Fop in
lower case in their names was a mistake that was discovered after the
API was frozen. Let’s not do that mistake again.

There are quite a few typos in the javadocs of the new class, it would
be good to fix them.

src/java/org/apache/fop/apps/EnvironmentProfile.java
• class javadoc: “The environment profile represents the restrictions
  and allowances that FOP is”... what?

src/java/org/apache/fop/apps/EnvironmentalProfileFactory.java
• should be renamed into EnvironmentProfileFactory
• in the inner Profile class: there are checks that constructor
  parameters are not null, except for FontManager. So may that be null
  then? Doesn’t look like.

src/java/org/apache/fop/apps/FOUserAgent.java
• left-over TODO in resolveURI: should that be left as-is for now?
• getRendererConfig(String mimeType, RendererConfigParser configCreator)
  isn’t there a risk of mismatch between the given mimeType and
  configCreator? Can’t the mimeType be taken from the
  RendererConfigParser.getMimeType method?
• getRendererConfiguration(String mimeType)
  This comment:
  // silently pass over configurations without mime type
  Really? Don’t we want to at least display a warning?
• public ColorSpaceCache getColorSpaceCache() {
  /** TODO: javadoc*/
• getHyphPatNames()
  this is hard to pronounce; also ‘Pat’ can easily be mistaken for
  ‘Path’
  s/getHyphPatNames/getHyphenationPatternNames/?

src/java/org/apache/fop/apps/FopConfParser.java
• there’s a mistake in the handling of ‘strict-validation’: this is
  related to checking the conformance of XSL-FO documents against the
  spec. The setting to strictly check the validity of config files is
  ‘strict-configuration’

src/java/org/apache/fop/apps/FopFactoryBuilder.java
• the buildConfig method is deprecated but is used by the build method
  underneath, which is itself not deprecated. But then it shouldn’t rely
  on a deprecated method?

src/java/org/apache/fop/apps/FopFactoryConfig.java
• This is an interface whose methods’ javadocs refer to the FopFactory
  concrete class. So an abstraction depends on a concrete
  implementation. Surely that should be the other way around?

src/java/org/apache/fop/apps/io/InternalResourceResolver
• what does ‘Internal’ stand for?
• getBaseURI: I don’t think adding a slash at the end of the URI if it’s
  not there is desirable, because that effectively changes the base URI.
  That may lead to very confusing errors.

src/java/org/apache/fop/apps/io/TempResourceResolver
• unless I’m mistaken there’s no way of releasing the temporary resource
  once it’s no longer needed. The DefaultTempResourceResolver
  implementation deleteOnExits the file but this may not be enough if
  FOP is run on a server that is meant to (almost) never shut down. Or
  did I miss something?
• in DefaultTempResourceResolver.getTempFile: the File.createTempFile
  method should be used instead of querying the ‘java.io.tmpdir’
  property.

src/java/org/apache/fop/fonts/FontConfig.java
• all this interface declares is an inner FontConfigParser interface.
  Why not simply promote FontConfigParser as a top-level interface and
  remove FontConfig?

src/java/org/apache/fop/fonts/FontConfigurator.java
• some documentation about the T generic parameter would be good. Also,
  shouldn’t this parameter be bounded by some interface?

Thanks,
Vincent


On 03/07/12 10:35, mehdi houshmand wrote:
> Thanks guys, that's 5 x +1 and no one in opposition. I'll merge in the
> branch imminently and update the docs as appropriate
> 
> On 2 July 2012 14:40, Glenn Adams <gl...@skynav.com> wrote:
> 
>>
>> On Mon, Jul 2, 2012 at 7:25 AM, mehdi houshmand <me...@gmail.com> wrote:
>>
>>> 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.
>>>
>>
>> Go ahead. I'm going to rename the fop_1.1rc1 branch to fop_1.1 and then
>> create a fop_1.1rc1 tag on that branch that corresponds with the current
>> rc1 rev.
>>
> 

Re: [VOTE] Merge Temp_URI_Unification

[mehdi houshmand <me...@gmail.com>]

Thanks guys, that's 5 x +1 and no one in opposition. I'll merge in the
branch imminently and update the docs as appropriate

On 2 July 2012 14:40, Glenn Adams <gl...@skynav.com> wrote:

>
> On Mon, Jul 2, 2012 at 7:25 AM, mehdi houshmand <me...@gmail.com> wrote:
>
>> 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.
>>
>
> Go ahead. I'm going to rename the fop_1.1rc1 branch to fop_1.1 and then
> create a fop_1.1rc1 tag on that branch that corresponds with the current
> rc1 rev.
>

Re: [VOTE] Merge Temp_URI_Unification

[Vincent Hennebert <vh...@gmail.com>]

On 02/07/12 14:40, Glenn Adams wrote:
> On Mon, Jul 2, 2012 at 7:25 AM, mehdi houshmand <me...@gmail.com> wrote:
> 
>> 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.
>>
> 
> Go ahead. I'm going to rename the fop_1.1rc1 branch to fop_1.1 and then
> create a fop_1.1rc1 tag on that branch that corresponds with the current
> rc1 rev.

Having a fop-1_1 branch and creating tags is actually the way to
proceed. In fact, the tag should be created prior to the vote, that
should refer to it.

To answer Pascal’s question: it doesn’t matter if there are enhancements
during the release process. The corresponding commits can be blocked
using ‘svn merge -c <revnum> --record-only’. That way, only the relevant
changes can be merged to the branch.

Vincent

Re: [VOTE] Merge Temp_URI_Unification

[Glenn Adams <gl...@skynav.com>]

On Mon, Jul 2, 2012 at 7:25 AM, mehdi houshmand <me...@gmail.com> wrote:

> 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.
>

Go ahead. I'm going to rename the fop_1.1rc1 branch to fop_1.1 and then
create a fop_1.1rc1 tag on that branch that corresponds with the current
rc1 rev.

Re: [VOTE] Merge Temp_URI_Unification

[mehdi houshmand <me...@gmail.com>]

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 <ps...@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 <me...@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 <ps...@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 <me...@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 <ps...@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 <bo...@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
> >> >> >> <ma...@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
>

Re: [VOTE] Merge Temp_URI_Unification

[Pascal Sancho <ps...@gmail.com>]

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 <me...@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 <ps...@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 <me...@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 <ps...@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 <bo...@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
>> >> >> <ma...@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

Re: [VOTE] Merge Temp_URI_Unification

[mehdi houshmand <me...@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 <ps...@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 <me...@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 <ps...@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 <bo...@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
> >> >> <ma...@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
> >
> >
>
>
>
> --
> pascal
>

Re: [VOTE] Merge Temp_URI_Unification

[Pascal Sancho <ps...@gmail.com>]

Sorry, an unwanted key stroke...

2012/7/2 Pascal Sancho <ps...@gmail.com>:
> 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
made from trunk, including further changes.
That will need further tests and RC, so no final release until...?

Perhaps we have to decide now what will be in 1.1 final release.

> 2012/7/2 mehdi houshmand <me...@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 <ps...@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 <bo...@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
>>> >> <ma...@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

Re: [VOTE] Merge Temp_URI_Unification

[Pascal Sancho <ps...@gmail.com>]

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 <me...@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 <ps...@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 <bo...@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
>> >> <ma...@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
>
>



-- 
pascal

Re: [VOTE] Merge Temp_URI_Unification

[mehdi houshmand <me...@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 <ps...@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 <bo...@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
> >> <ma...@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
>

Re: [VOTE] Merge Temp_URI_Unification

[Pascal Sancho <ps...@gmail.com>]

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 <bo...@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
>> <ma...@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

Re: [VOTE] Merge Temp_URI_Unification

[Chris Bowditch <bo...@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 
> <ma...@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.
>
>