Re: [VOTE] Merge Temp_URI_Unification

[mehdi houshmand]

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 bowditch_ch...@hotmail.com wrote:

 On 04/07/2012 17:15, Glenn Adams wrote:


 On Wed, Jul 4, 2012 at 9:25 AM, mehdi houshmand med1...@gmail.commailto:
 med1...@gmail.com wrote:

 On 4 July 2012 12:32, Vincent Hennebert vhenneb...@gmail.com
 mailto:vhenneb...@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]

On Thu, Jul 5, 2012 at 12:41 AM, mehdi houshmand med1...@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

[Peter Hancock]

Hi Vincent, FOP Dev,

On Wed, Jul 4, 2012 at 12:32 PM, Vincent Hennebert vhenneb...@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

[mehdi houshmand]

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 med1...@gmail.comwrote:

 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]

On 3 July 2012 15:48, Vincent Hennebert vhenneb...@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 

Re: [VOTE] Merge Temp_URI_Unification

[mehdi houshmand]

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 med1...@gmail.com wrote:



 On 3 July 2012 15:48, Vincent Hennebert vhenneb...@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 

Re: [VOTE] Merge Temp_URI_Unification

[Vincent Hennebert]

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 

Re: [VOTE] Merge Temp_URI_Unification

[mehdi houshmand]

On 4 July 2012 12:32, Vincent Hennebert vhenneb...@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 

Re: [VOTE] Merge Temp_URI_Unification

[Glenn Adams]

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

 On 4 July 2012 12:32, Vincent Hennebert vhenneb...@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

[Chris Bowditch]

On 04/07/2012 17:15, Glenn Adams wrote:


On Wed, Jul 4, 2012 at 9:25 AM, mehdi houshmand med1...@gmail.com 
mailto:med1...@gmail.com wrote:


On 4 July 2012 12:32, Vincent Hennebert vhenneb...@gmail.com
mailto:vhenneb...@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]

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
--
the.webmaes...@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
bowditch_ch...@hotmail.com wrote:
 On 04/07/2012 17:15, Glenn Adams wrote:


 On Wed, Jul 4, 2012 at 9:25 AM, mehdi houshmand med1...@gmail.com
 mailto:med1...@gmail.com wrote:

 On 4 July 2012 12:32, Vincent Hennebert vhenneb...@gmail.com
 mailto:vhenneb...@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]

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 the.webmaes...@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
 --
 the.webmaes...@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
 bowditch_ch...@hotmail.com wrote:
  On 04/07/2012 17:15, Glenn Adams wrote:
 
 
  On Wed, Jul 4, 2012 at 9:25 AM, mehdi houshmand med1...@gmail.com
  mailto:med1...@gmail.com wrote:
 
  On 4 July 2012 12:32, Vincent Hennebert vhenneb...@gmail.com
  mailto:vhenneb...@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

[Clay Leeds]

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 med1...@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 the.webmaes...@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
 --
 the.webmaes...@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
 bowditch_ch...@hotmail.com wrote:
  On 04/07/2012 17:15, Glenn Adams wrote:
 
 
  On Wed, Jul 4, 2012 at 9:25 AM, mehdi houshmand med1...@gmail.com
  mailto:med1...@gmail.com wrote:
 
  On 4 July 2012 12:32, Vincent Hennebert vhenneb...@gmail.com
  mailto:vhenneb...@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

[Alexios Giotis]

 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

[mehdi houshmand]

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 med1...@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]

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 med1...@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]

On 02/07/12 14:40, Glenn Adams wrote:
 On Mon, Jul 2, 2012 at 7:25 AM, mehdi houshmand med1...@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

[Peter Hancock]

+1

On Tue, Jun 26, 2012 at 3:39 PM, mehdi houshmand med1...@gmail.com wrote:
 Sorry, added [VOTE] to subject line... My bad

 On 26 June 2012 15:38, mehdi houshmand med1...@gmail.com wrote:

 Hi All,



 I think we've got to the stage in the URI unification branch where it's
 ready to be merged into trunk (not into 1.1RC1). I know there have been
 proponents against the inclusion of this feature and/or those who are
 concerned the wider implications as it means FOP has fewer contingency
 methods when attempting file access. I'll try and explain how we've
 addressed those concerns as well as some of the code improvements we've
 made.



 - Syntactic URI fall-back mechanisms - if a URI is syntactically erroneous
 i.e. contains white-space, \ instead of /, we do some validation on to
 mitigate some of the common mistakes. However, we don't allow for falling
 back to 'new File(.)' or new URL(...).openStream() since these can
 obviously cause clashes in a highly parallelised multi-tenant environment.



 - Single FOP conf parse - Previously the renderer specific regions of the
 FOP conf was being parsed on every run. This is costly to performance for
 the obvious reason, but as well as this, it meant that font auto-detection
 was having to be executed on every run. The font-caching was created to
 mitigate some of those performance costs, however, caching the FOP conf
 makes much more sense. It means we can get rid of the font-caching and don't
 have to to worry about performance but it also allowed to do a lot of clean
 up in the configuration packages. The renderer specific config is also lazy
 loaded such that it is only parsed when the respective renderer is invoked,
 mitigating the one-off cost of parsing that config.



 - The environment profile - We've created an environment profile that
 abstracts the system in which FOP is invoked. This allows us to
 programmatically enforce restrictions to, for example, font-caching and
 auto-detection since users may want to control this behaviour for any number
 of reasons.



 - Improved URI handling - because the URI resolution has been unified to a
 couple of classes, the behaviour is much easier for users to understand.



 - Consistent base directories - We've tried to ensure that base
 directories are consistent with FOP previously, the base and font-base
 still work as previously.



 There are however some outstanding TODOs that need to be addressed,
 however, though they are important, they don't need to be all merged in at
 the same time. I will be working on these and keep the community updated:



 TODOs//



 - XGC and libraries - This is most likely the next project, we need to do
 the same in the XGC project and look at some of FOPs dependencies (Batik
 too!). The plan will be to move all the resource resolver classes to XGC
 since that is the parent library so that they can be used though out the
 XMLGraphics libraries.



 - Improved MIME type resolution - currently FOP's file-type
 (file-MIME-type) is performed in-situ using file-name endings. This is,
 while working perfectly fine on a desktop environment, would be less than
 desirable if file-names were just hashes or the like from a virtual
 file-system. We need to give the user the flexibility to define a file MIME
 type without forcing them to put the file-ending in the URI.

 - Default handling in some of the Configurators - We have improved the
 mechanism that handles default values in the configuration as well as config
 injected via RendererOptions (on the FOUserAgent) and the FOP conf for PDF.
 However, time constraints haven't allowed us to do the same for PS and AFP,
 which would be nice to do. This isn't of utmost priority, but it would be
 nice to not have the if (x != null) peppered around the source

 Sorry for the long email, I just thought it'd be a good time to expose
 some of the work we've been doing,

 Mehdi


 P.S. More information can be found wiki under the developers section, it's
 currently down so I can't post a link.

Re: [VOTE] Merge Temp_URI_Unification

[Chris Bowditch]

On 26/06/2012 15:39, mehdi houshmand wrote:

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


+1 from me. Good work Mehdi and Pete.

Chris



On 26 June 2012 15:38, mehdi houshmand med1...@gmail.com 
mailto:med1...@gmail.com wrote:


Hi All,

I think we've got to the stage in the URI unification branch where
it's ready to be merged into trunk (not into 1.1RC1). I know there
have been proponents against the inclusion of this feature and/or
those who are concerned the wider implications as it means FOP has
fewer contingency methods when attempting file access. I'll try
and explain how we've addressed those concerns as well as some of
the code improvements we've made.

- Syntactic URI fall-back mechanisms - if a URI is syntactically
erroneous i.e. contains white-space, \ instead of /, we do
some validation on to mitigate some of the common mistakes.
However, we don't allow for falling back to 'new File(.)' or
new URL(...).openStream() since these can obviously cause
clashes in a highly parallelised multi-tenant environment.

- Single FOP conf parse - Previously the renderer specific regions
of the FOP conf was being parsed on every run. This is costly to
performance for the obvious reason, but as well as this, it meant
that font auto-detection was having to be executed on every run.
The font-caching was created to mitigate some of those performance
costs, however, caching the FOP conf makes much more sense. It
means we can get rid of the font-caching and don't have to to
worry about performance but it also allowed to do a lot of clean
up in the configuration packages. The renderer specific config is
also lazy loaded such that it is only parsed when the respective
renderer is invoked, mitigating the one-off cost of parsing that
config.

- The environment profile - We've created an environment profile
that abstracts the system in which FOP is invoked. This allows us
to programmatically enforce restrictions to, for example,
font-caching and auto-detection since users may want to control
this behaviour for any number of reasons.

- Improved URI handling - because the URI resolution has been
unified to a couple of classes, the behaviour is much easier for
users to understand.

- Consistent base directories - We've tried to ensure that base
directories are consistent with FOP previously, the base and
font-base still work as previously.

There are however some outstanding TODOs that need to be
addressed, however, though they are important, they don't need to
be all merged in at the same time. I will be working on these and
keep the community updated:

TODOs//

- XGC and libraries - This is most likely the next project, we
need to do the same in the XGC project and look at some of FOPs
dependencies (Batik too!). The plan will be to move all the
resource resolver classes to XGC since that is the parent library
so that they can be used though out the XMLGraphics libraries.

- Improved MIME type resolution - currently FOP's file-type
(file-MIME-type) is performed in-situ using file-name endings.
This is, while working perfectly fine on a desktop environment,
would be less than desirable if file-names were just hashes or the
like from a virtual file-system. We need to give the user the
flexibility to define a file MIME type without forcing them to put
the file-ending in the URI.

- Default handling in some of the Configurators - We have improved
the mechanism that handles default values in the configuration as
well as config injected via RendererOptions (on the FOUserAgent)
and the FOP conf for PDF. However, time constraints haven't
allowed us to do the same for PS and AFP, which would be nice to
do. This isn't of utmost priority, but it would be nice to not
have the if (x != null) peppered around the source

Sorry for the long email, I just thought it'd be a good time to
expose some of the work we've been doing,

Mehdi


P.S. More information can be found wiki under the developers
section, it's currently down so I can't post a link.

Re: [VOTE] Merge Temp_URI_Unification

[Pascal Sancho]

Hi,

+1 for merging it to trunk.

That said, I'm a little puzzled with the release process.
In my mind, a RC should come before a production release, freezing all features.
Only bugfix should be permitted on RC.
Adding new feature to RC2 is a precedent that allows to add a new
feature after each RC, witch need to release a new... RC, etc.
I humbly suggest that the release process start with a 1.1 branch,
from witch RCx and final release will be tagged, that should allow to
continue merging branches onto trunk without any interaction on branch
release.
WDYT?

2012/7/2 Chris Bowditch bowditch_ch...@hotmail.com:
 On 26/06/2012 15:39, mehdi houshmand wrote:

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


 +1 from me. Good work Mehdi and Pete.

 Chris



 On 26 June 2012 15:38, mehdi houshmand med1...@gmail.com
 mailto:med1...@gmail.com wrote:

 Hi All,

 I think we've got to the stage in the URI unification branch where
 it's ready to be merged into trunk (not into 1.1RC1). I know there
 have been proponents against the inclusion of this feature and/or
 those who are concerned the wider implications as it means FOP has
 fewer contingency methods when attempting file access. I'll try
 and explain how we've addressed those concerns as well as some of
 the code improvements we've made.

 - Syntactic URI fall-back mechanisms - if a URI is syntactically
 erroneous i.e. contains white-space, \ instead of /, we do
 some validation on to mitigate some of the common mistakes.
 However, we don't allow for falling back to 'new File(.)' or
 new URL(...).openStream() since these can obviously cause
 clashes in a highly parallelised multi-tenant environment.

 - Single FOP conf parse - Previously the renderer specific regions
 of the FOP conf was being parsed on every run. This is costly to
 performance for the obvious reason, but as well as this, it meant
 that font auto-detection was having to be executed on every run.
 The font-caching was created to mitigate some of those performance
 costs, however, caching the FOP conf makes much more sense. It
 means we can get rid of the font-caching and don't have to to
 worry about performance but it also allowed to do a lot of clean
 up in the configuration packages. The renderer specific config is
 also lazy loaded such that it is only parsed when the respective
 renderer is invoked, mitigating the one-off cost of parsing that
 config.

 - The environment profile - We've created an environment profile
 that abstracts the system in which FOP is invoked. This allows us
 to programmatically enforce restrictions to, for example,
 font-caching and auto-detection since users may want to control
 this behaviour for any number of reasons.

 - Improved URI handling - because the URI resolution has been
 unified to a couple of classes, the behaviour is much easier for
 users to understand.

 - Consistent base directories - We've tried to ensure that base
 directories are consistent with FOP previously, the base and
 font-base still work as previously.

 There are however some outstanding TODOs that need to be
 addressed, however, though they are important, they don't need to
 be all merged in at the same time. I will be working on these and
 keep the community updated:

 TODOs//

 - XGC and libraries - This is most likely the next project, we
 need to do the same in the XGC project and look at some of FOPs
 dependencies (Batik too!). The plan will be to move all the
 resource resolver classes to XGC since that is the parent library
 so that they can be used though out the XMLGraphics libraries.

 - Improved MIME type resolution - currently FOP's file-type
 (file-MIME-type) is performed in-situ using file-name endings.
 This is, while working perfectly fine on a desktop environment,
 would be less than desirable if file-names were just hashes or the
 like from a virtual file-system. We need to give the user the
 flexibility to define a file MIME type without forcing them to put
 the file-ending in the URI.

 - Default handling in some of the Configurators - We have improved
 the mechanism that handles default values in the configuration as
 well as config injected via RendererOptions (on the FOUserAgent)
 and the FOP conf for PDF. However, time constraints haven't
 allowed us to do the same for PS and AFP, which would be nice to
 do. This isn't of utmost priority, but it would be nice to not
 have the if (x != null) peppered around the source

 Sorry for the long email, I just thought it'd be a good time to
 expose some of the work we've been doing,

 Mehdi


 P.S. More information can be found wiki under the developers
 section, it's currently down so I can't post a link.







-- 
pascal

Re: [VOTE] Merge Temp_URI_Unification

[mehdi houshmand]

Hi Pascal,

I won't be merging this into anything other than trunk. Sorry, maybe I
should have made that more explicit.

Mehdi

On 2 July 2012 12:32, Pascal Sancho psancho@gmail.com wrote:

 Hi,

 +1 for merging it to trunk.

 That said, I'm a little puzzled with the release process.
 In my mind, a RC should come before a production release, freezing all
 features.
 Only bugfix should be permitted on RC.
 Adding new feature to RC2 is a precedent that allows to add a new
 feature after each RC, witch need to release a new... RC, etc.
 I humbly suggest that the release process start with a 1.1 branch,
 from witch RCx and final release will be tagged, that should allow to
 continue merging branches onto trunk without any interaction on branch
 release.
 WDYT?

 2012/7/2 Chris Bowditch bowditch_ch...@hotmail.com:
  On 26/06/2012 15:39, mehdi houshmand wrote:
 
  Sorry, added [VOTE] to subject line... My bad
 
 
  +1 from me. Good work Mehdi and Pete.
 
  Chris
 
 
 
  On 26 June 2012 15:38, mehdi houshmand med1...@gmail.com
  mailto:med1...@gmail.com wrote:
 
  Hi All,
 
  I think we've got to the stage in the URI unification branch where
  it's ready to be merged into trunk (not into 1.1RC1). I know there
  have been proponents against the inclusion of this feature and/or
  those who are concerned the wider implications as it means FOP has
  fewer contingency methods when attempting file access. I'll try
  and explain how we've addressed those concerns as well as some of
  the code improvements we've made.
 
  - Syntactic URI fall-back mechanisms - if a URI is syntactically
  erroneous i.e. contains white-space, \ instead of /, we do
  some validation on to mitigate some of the common mistakes.
  However, we don't allow for falling back to 'new File(.)' or
  new URL(...).openStream() since these can obviously cause
  clashes in a highly parallelised multi-tenant environment.
 
  - Single FOP conf parse - Previously the renderer specific regions
  of the FOP conf was being parsed on every run. This is costly to
  performance for the obvious reason, but as well as this, it meant
  that font auto-detection was having to be executed on every run.
  The font-caching was created to mitigate some of those performance
  costs, however, caching the FOP conf makes much more sense. It
  means we can get rid of the font-caching and don't have to to
  worry about performance but it also allowed to do a lot of clean
  up in the configuration packages. The renderer specific config is
  also lazy loaded such that it is only parsed when the respective
  renderer is invoked, mitigating the one-off cost of parsing that
  config.
 
  - The environment profile - We've created an environment profile
  that abstracts the system in which FOP is invoked. This allows us
  to programmatically enforce restrictions to, for example,
  font-caching and auto-detection since users may want to control
  this behaviour for any number of reasons.
 
  - Improved URI handling - because the URI resolution has been
  unified to a couple of classes, the behaviour is much easier for
  users to understand.
 
  - Consistent base directories - We've tried to ensure that base
  directories are consistent with FOP previously, the base and
  font-base still work as previously.
 
  There are however some outstanding TODOs that need to be
  addressed, however, though they are important, they don't need to
  be all merged in at the same time. I will be working on these and
  keep the community updated:
 
  TODOs//
 
  - XGC and libraries - This is most likely the next project, we
  need to do the same in the XGC project and look at some of FOPs
  dependencies (Batik too!). The plan will be to move all the
  resource resolver classes to XGC since that is the parent library
  so that they can be used though out the XMLGraphics libraries.
 
  - Improved MIME type resolution - currently FOP's file-type
  (file-MIME-type) is performed in-situ using file-name endings.
  This is, while working perfectly fine on a desktop environment,
  would be less than desirable if file-names were just hashes or the
  like from a virtual file-system. We need to give the user the
  flexibility to define a file MIME type without forcing them to put
  the file-ending in the URI.
 
  - Default handling in some of the Configurators - We have improved
  the mechanism that handles default values in the configuration as
  well as config injected via RendererOptions (on the FOUserAgent)
  and the FOP conf for PDF. However, time constraints haven't
  allowed us to do the same for PS and AFP, which would be nice to
  do. This isn't of utmost priority, but it would be nice to not
  have the if (x != null) peppered around the source
 
  Sorry 

Re: [VOTE] Merge Temp_URI_Unification

[Pascal Sancho]

Mehdi,

I speak about post 1.1RC1.
Your merge will be against the trunk.
What about the 1.1RC2 or 1.1 final?
In the current usage, *all* FOP releases are tagged directly from
trunk (via a branch that is only to set FOP version and lib
dependencies).
So, every further RC or final releases are planed to be ma
2012/7/2 mehdi houshmand med1...@gmail.com:
 Hi Pascal,

 I won't be merging this into anything other than trunk. Sorry, maybe I
 should have made that more explicit.

 Mehdi


 On 2 July 2012 12:32, Pascal Sancho psancho@gmail.com wrote:

 Hi,

 +1 for merging it to trunk.

 That said, I'm a little puzzled with the release process.
 In my mind, a RC should come before a production release, freezing all
 features.
 Only bugfix should be permitted on RC.
 Adding new feature to RC2 is a precedent that allows to add a new
 feature after each RC, witch need to release a new... RC, etc.
 I humbly suggest that the release process start with a 1.1 branch,
 from witch RCx and final release will be tagged, that should allow to
 continue merging branches onto trunk without any interaction on branch
 release.
 WDYT?

 2012/7/2 Chris Bowditch bowditch_ch...@hotmail.com:
  On 26/06/2012 15:39, mehdi houshmand wrote:
 
  Sorry, added [VOTE] to subject line... My bad
 
 
  +1 from me. Good work Mehdi and Pete.
 
  Chris
 
 
 
  On 26 June 2012 15:38, mehdi houshmand med1...@gmail.com
  mailto:med1...@gmail.com wrote:
 
  Hi All,
 
  I think we've got to the stage in the URI unification branch where
  it's ready to be merged into trunk (not into 1.1RC1). I know there
  have been proponents against the inclusion of this feature and/or
  those who are concerned the wider implications as it means FOP has
  fewer contingency methods when attempting file access. I'll try
  and explain how we've addressed those concerns as well as some of
  the code improvements we've made.
 
  - Syntactic URI fall-back mechanisms - if a URI is syntactically
  erroneous i.e. contains white-space, \ instead of /, we do
  some validation on to mitigate some of the common mistakes.
  However, we don't allow for falling back to 'new File(.)' or
  new URL(...).openStream() since these can obviously cause
  clashes in a highly parallelised multi-tenant environment.
 
  - Single FOP conf parse - Previously the renderer specific regions
  of the FOP conf was being parsed on every run. This is costly to
  performance for the obvious reason, but as well as this, it meant
  that font auto-detection was having to be executed on every run.
  The font-caching was created to mitigate some of those performance
  costs, however, caching the FOP conf makes much more sense. It
  means we can get rid of the font-caching and don't have to to
  worry about performance but it also allowed to do a lot of clean
  up in the configuration packages. The renderer specific config is
  also lazy loaded such that it is only parsed when the respective
  renderer is invoked, mitigating the one-off cost of parsing that
  config.
 
  - The environment profile - We've created an environment profile
  that abstracts the system in which FOP is invoked. This allows us
  to programmatically enforce restrictions to, for example,
  font-caching and auto-detection since users may want to control
  this behaviour for any number of reasons.
 
  - Improved URI handling - because the URI resolution has been
  unified to a couple of classes, the behaviour is much easier for
  users to understand.
 
  - Consistent base directories - We've tried to ensure that base
  directories are consistent with FOP previously, the base and
  font-base still work as previously.
 
  There are however some outstanding TODOs that need to be
  addressed, however, though they are important, they don't need to
  be all merged in at the same time. I will be working on these and
  keep the community updated:
 
  TODOs//
 
  - XGC and libraries - This is most likely the next project, we
  need to do the same in the XGC project and look at some of FOPs
  dependencies (Batik too!). The plan will be to move all the
  resource resolver classes to XGC since that is the parent library
  so that they can be used though out the XMLGraphics libraries.
 
  - Improved MIME type resolution - currently FOP's file-type
  (file-MIME-type) is performed in-situ using file-name endings.
  This is, while working perfectly fine on a desktop environment,
  would be less than desirable if file-names were just hashes or the
  like from a virtual file-system. We need to give the user the
  flexibility to define a file MIME type without forcing them to put
  the file-ending in the URI.
 
  - Default handling in some of the Configurators - We have improved
  the mechanism that handles default values in the 

Re: [VOTE] Merge Temp_URI_Unification

[Pascal Sancho]

Sorry, an unwanted key stroke...

2012/7/2 Pascal Sancho psancho@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 med1...@gmail.com:
 Hi Pascal,

 I won't be merging this into anything other than trunk. Sorry, maybe I
 should have made that more explicit.

 Mehdi


 On 2 July 2012 12:32, Pascal Sancho psancho@gmail.com wrote:

 Hi,

 +1 for merging it to trunk.

 That said, I'm a little puzzled with the release process.
 In my mind, a RC should come before a production release, freezing all
 features.
 Only bugfix should be permitted on RC.
 Adding new feature to RC2 is a precedent that allows to add a new
 feature after each RC, witch need to release a new... RC, etc.
 I humbly suggest that the release process start with a 1.1 branch,
 from witch RCx and final release will be tagged, that should allow to
 continue merging branches onto trunk without any interaction on branch
 release.
 WDYT?

 2012/7/2 Chris Bowditch bowditch_ch...@hotmail.com:
  On 26/06/2012 15:39, mehdi houshmand wrote:
 
  Sorry, added [VOTE] to subject line... My bad
 
 
  +1 from me. Good work Mehdi and Pete.
 
  Chris
 
 
 
  On 26 June 2012 15:38, mehdi houshmand med1...@gmail.com
  mailto:med1...@gmail.com wrote:
 
  Hi All,
 
  I think we've got to the stage in the URI unification branch where
  it's ready to be merged into trunk (not into 1.1RC1). I know there
  have been proponents against the inclusion of this feature and/or
  those who are concerned the wider implications as it means FOP has
  fewer contingency methods when attempting file access. I'll try
  and explain how we've addressed those concerns as well as some of
  the code improvements we've made.
 
  - Syntactic URI fall-back mechanisms - if a URI is syntactically
  erroneous i.e. contains white-space, \ instead of /, we do
  some validation on to mitigate some of the common mistakes.
  However, we don't allow for falling back to 'new File(.)' or
  new URL(...).openStream() since these can obviously cause
  clashes in a highly parallelised multi-tenant environment.
 
  - Single FOP conf parse - Previously the renderer specific regions
  of the FOP conf was being parsed on every run. This is costly to
  performance for the obvious reason, but as well as this, it meant
  that font auto-detection was having to be executed on every run.
  The font-caching was created to mitigate some of those performance
  costs, however, caching the FOP conf makes much more sense. It
  means we can get rid of the font-caching and don't have to to
  worry about performance but it also allowed to do a lot of clean
  up in the configuration packages. The renderer specific config is
  also lazy loaded such that it is only parsed when the respective
  renderer is invoked, mitigating the one-off cost of parsing that
  config.
 
  - The environment profile - We've created an environment profile
  that abstracts the system in which FOP is invoked. This allows us
  to programmatically enforce restrictions to, for example,
  font-caching and auto-detection since users may want to control
  this behaviour for any number of reasons.
 
  - Improved URI handling - because the URI resolution has been
  unified to a couple of classes, the behaviour is much easier for
  users to understand.
 
  - Consistent base directories - We've tried to ensure that base
  directories are consistent with FOP previously, the base and
  font-base still work as previously.
 
  There are however some outstanding TODOs that need to be
  addressed, however, though they are important, they don't need to
  be all merged in at the same time. I will be working on these and
  keep the community updated:
 
  TODOs//
 
  - XGC and libraries - This is most likely the next project, we
  need to do the same in the XGC project and look at some of FOPs
  dependencies (Batik too!). The plan will be to move all the
  resource resolver classes to XGC since that is the parent library
  so that they can be used though out the XMLGraphics libraries.
 
  - Improved MIME type resolution - currently FOP's file-type
  (file-MIME-type) is performed in-situ using file-name endings.
  This is, while working perfectly fine on a desktop environment,
  would be less than desirable if file-names were just hashes or the
  like from a virtual file-system. We need 

Re: [VOTE] Merge Temp_URI_Unification

[mehdi houshmand]

Excuse my ignorance here, but why do any changes to trunk affect 1.1RC*?
The 1.1 branch has already been defined and voted upon, I don't see how any
changes to trunk would affect it? I'm not very familiar with the FOPs
releasing process so do excuse me.

Mehdi

On 2 July 2012 13:42, Pascal Sancho psancho@gmail.com wrote:

 Mehdi,

 I speak about post 1.1RC1.
 Your merge will be against the trunk.
 What about the 1.1RC2 or 1.1 final?
 In the current usage, *all* FOP releases are tagged directly from
 trunk (via a branch that is only to set FOP version and lib
 dependencies).
 So, every further RC or final releases are planed to be ma
 2012/7/2 mehdi houshmand med1...@gmail.com:
  Hi Pascal,
 
  I won't be merging this into anything other than trunk. Sorry, maybe I
  should have made that more explicit.
 
  Mehdi
 
 
  On 2 July 2012 12:32, Pascal Sancho psancho@gmail.com wrote:
 
  Hi,
 
  +1 for merging it to trunk.
 
  That said, I'm a little puzzled with the release process.
  In my mind, a RC should come before a production release, freezing all
  features.
  Only bugfix should be permitted on RC.
  Adding new feature to RC2 is a precedent that allows to add a new
  feature after each RC, witch need to release a new... RC, etc.
  I humbly suggest that the release process start with a 1.1 branch,
  from witch RCx and final release will be tagged, that should allow to
  continue merging branches onto trunk without any interaction on branch
  release.
  WDYT?
 
  2012/7/2 Chris Bowditch bowditch_ch...@hotmail.com:
   On 26/06/2012 15:39, mehdi houshmand wrote:
  
   Sorry, added [VOTE] to subject line... My bad
  
  
   +1 from me. Good work Mehdi and Pete.
  
   Chris
  
  
  
   On 26 June 2012 15:38, mehdi houshmand med1...@gmail.com
   mailto:med1...@gmail.com wrote:
  
   Hi All,
  
   I think we've got to the stage in the URI unification branch
 where
   it's ready to be merged into trunk (not into 1.1RC1). I know
 there
   have been proponents against the inclusion of this feature and/or
   those who are concerned the wider implications as it means FOP
 has
   fewer contingency methods when attempting file access. I'll try
   and explain how we've addressed those concerns as well as some of
   the code improvements we've made.
  
   - Syntactic URI fall-back mechanisms - if a URI is syntactically
   erroneous i.e. contains white-space, \ instead of /, we do
   some validation on to mitigate some of the common mistakes.
   However, we don't allow for falling back to 'new File(.)' or
   new URL(...).openStream() since these can obviously cause
   clashes in a highly parallelised multi-tenant environment.
  
   - Single FOP conf parse - Previously the renderer specific
 regions
   of the FOP conf was being parsed on every run. This is costly to
   performance for the obvious reason, but as well as this, it meant
   that font auto-detection was having to be executed on every run.
   The font-caching was created to mitigate some of those
 performance
   costs, however, caching the FOP conf makes much more sense. It
   means we can get rid of the font-caching and don't have to to
   worry about performance but it also allowed to do a lot of clean
   up in the configuration packages. The renderer specific config is
   also lazy loaded such that it is only parsed when the respective
   renderer is invoked, mitigating the one-off cost of parsing that
   config.
  
   - The environment profile - We've created an environment profile
   that abstracts the system in which FOP is invoked. This allows us
   to programmatically enforce restrictions to, for example,
   font-caching and auto-detection since users may want to control
   this behaviour for any number of reasons.
  
   - Improved URI handling - because the URI resolution has been
   unified to a couple of classes, the behaviour is much easier for
   users to understand.
  
   - Consistent base directories - We've tried to ensure that base
   directories are consistent with FOP previously, the base and
   font-base still work as previously.
  
   There are however some outstanding TODOs that need to be
   addressed, however, though they are important, they don't need to
   be all merged in at the same time. I will be working on these and
   keep the community updated:
  
   TODOs//
  
   - XGC and libraries - This is most likely the next project, we
   need to do the same in the XGC project and look at some of FOPs
   dependencies (Batik too!). The plan will be to move all the
   resource resolver classes to XGC since that is the parent library
   so that they can be used though out the XMLGraphics libraries.
  
   - Improved MIME type resolution - currently FOP's file-type
   (file-MIME-type) is performed in-situ using file-name endings.
   This 

Re: [VOTE] Merge Temp_URI_Unification

[Pascal Sancho]

Sorry Mehdi, I realize that I started a new discussion.
Merging your development branch onto the trunk is not what puzzled me.
This has to be done as this.

What I said is: currently there are concurrent enhancements and releases.
So, between the 1st RC and the final release there can be a lot of
differences, witch is not --from my point of view-- a good thing.

IIRC, the 1.1 vote was for the 1.1RC1, not for the 1.1 branch witch
doesn't exist.
But I agree with you: it a such branch 1.1 should exist ;-)


2012/7/2 mehdi houshmand med1...@gmail.com:
 Excuse my ignorance here, but why do any changes to trunk affect 1.1RC*? The
 1.1 branch has already been defined and voted upon, I don't see how any
 changes to trunk would affect it? I'm not very familiar with the FOPs
 releasing process so do excuse me.

 Mehdi


 On 2 July 2012 13:42, Pascal Sancho psancho@gmail.com wrote:

 Mehdi,

 I speak about post 1.1RC1.
 Your merge will be against the trunk.
 What about the 1.1RC2 or 1.1 final?
 In the current usage, *all* FOP releases are tagged directly from
 trunk (via a branch that is only to set FOP version and lib
 dependencies).
 So, every further RC or final releases are planed to be ma
 2012/7/2 mehdi houshmand med1...@gmail.com:
  Hi Pascal,
 
  I won't be merging this into anything other than trunk. Sorry, maybe I
  should have made that more explicit.
 
  Mehdi
 
 
  On 2 July 2012 12:32, Pascal Sancho psancho@gmail.com wrote:
 
  Hi,
 
  +1 for merging it to trunk.
 
  That said, I'm a little puzzled with the release process.
  In my mind, a RC should come before a production release, freezing all
  features.
  Only bugfix should be permitted on RC.
  Adding new feature to RC2 is a precedent that allows to add a new
  feature after each RC, witch need to release a new... RC, etc.
  I humbly suggest that the release process start with a 1.1 branch,
  from witch RCx and final release will be tagged, that should allow to
  continue merging branches onto trunk without any interaction on branch
  release.
  WDYT?
 
  2012/7/2 Chris Bowditch bowditch_ch...@hotmail.com:
   On 26/06/2012 15:39, mehdi houshmand wrote:
  
   Sorry, added [VOTE] to subject line... My bad
  
  
   +1 from me. Good work Mehdi and Pete.
  
   Chris
  
  
  
   On 26 June 2012 15:38, mehdi houshmand med1...@gmail.com
   mailto:med1...@gmail.com wrote:
  
   Hi All,
  
   I think we've got to the stage in the URI unification branch
   where
   it's ready to be merged into trunk (not into 1.1RC1). I know
   there
   have been proponents against the inclusion of this feature
   and/or
   those who are concerned the wider implications as it means FOP
   has
   fewer contingency methods when attempting file access. I'll try
   and explain how we've addressed those concerns as well as some
   of
   the code improvements we've made.
  
   - Syntactic URI fall-back mechanisms - if a URI is syntactically
   erroneous i.e. contains white-space, \ instead of /, we do
   some validation on to mitigate some of the common mistakes.
   However, we don't allow for falling back to 'new File(.)' or
   new URL(...).openStream() since these can obviously cause
   clashes in a highly parallelised multi-tenant environment.
  
   - Single FOP conf parse - Previously the renderer specific
   regions
   of the FOP conf was being parsed on every run. This is costly to
   performance for the obvious reason, but as well as this, it
   meant
   that font auto-detection was having to be executed on every run.
   The font-caching was created to mitigate some of those
   performance
   costs, however, caching the FOP conf makes much more sense. It
   means we can get rid of the font-caching and don't have to to
   worry about performance but it also allowed to do a lot of clean
   up in the configuration packages. The renderer specific config
   is
   also lazy loaded such that it is only parsed when the respective
   renderer is invoked, mitigating the one-off cost of parsing that
   config.
  
   - The environment profile - We've created an environment profile
   that abstracts the system in which FOP is invoked. This allows
   us
   to programmatically enforce restrictions to, for example,
   font-caching and auto-detection since users may want to control
   this behaviour for any number of reasons.
  
   - Improved URI handling - because the URI resolution has been
   unified to a couple of classes, the behaviour is much easier for
   users to understand.
  
   - Consistent base directories - We've tried to ensure that base
   directories are consistent with FOP previously, the base and
   font-base still work as previously.
  
   There are however some outstanding TODOs that need to be
   addressed, however, though they are important, they don't need
   to
   be all merged in at the same time. I 

Re: [VOTE] Merge Temp_URI_Unification

[mehdi houshmand]

Ahh I see, ok, thanks Pascal. I think we got our wires crossed a little
there ;)

Glenn, my plan was to merge the URI-resolution stuff in tomorrow. If this
burdens you in some way, could you let me know how and maybe we can come to
some resolution? As far as I can see, it shouldn't affect the 1.1rc1 branch
at all.

Mehdi

On 2 July 2012 14:19, Pascal Sancho psancho@gmail.com wrote:

 Sorry Mehdi, I realize that I started a new discussion.
 Merging your development branch onto the trunk is not what puzzled me.
 This has to be done as this.

 What I said is: currently there are concurrent enhancements and releases.
 So, between the 1st RC and the final release there can be a lot of
 differences, witch is not --from my point of view-- a good thing.

 IIRC, the 1.1 vote was for the 1.1RC1, not for the 1.1 branch witch
 doesn't exist.
 But I agree with you: it a such branch 1.1 should exist ;-)


 2012/7/2 mehdi houshmand med1...@gmail.com:
  Excuse my ignorance here, but why do any changes to trunk affect 1.1RC*?
 The
  1.1 branch has already been defined and voted upon, I don't see how any
  changes to trunk would affect it? I'm not very familiar with the FOPs
  releasing process so do excuse me.
 
  Mehdi
 
 
  On 2 July 2012 13:42, Pascal Sancho psancho@gmail.com wrote:
 
  Mehdi,
 
  I speak about post 1.1RC1.
  Your merge will be against the trunk.
  What about the 1.1RC2 or 1.1 final?
  In the current usage, *all* FOP releases are tagged directly from
  trunk (via a branch that is only to set FOP version and lib
  dependencies).
  So, every further RC or final releases are planed to be ma
  2012/7/2 mehdi houshmand med1...@gmail.com:
   Hi Pascal,
  
   I won't be merging this into anything other than trunk. Sorry, maybe I
   should have made that more explicit.
  
   Mehdi
  
  
   On 2 July 2012 12:32, Pascal Sancho psancho@gmail.com wrote:
  
   Hi,
  
   +1 for merging it to trunk.
  
   That said, I'm a little puzzled with the release process.
   In my mind, a RC should come before a production release, freezing
 all
   features.
   Only bugfix should be permitted on RC.
   Adding new feature to RC2 is a precedent that allows to add a new
   feature after each RC, witch need to release a new... RC, etc.
   I humbly suggest that the release process start with a 1.1 branch,
   from witch RCx and final release will be tagged, that should allow to
   continue merging branches onto trunk without any interaction on
 branch
   release.
   WDYT?
  
   2012/7/2 Chris Bowditch bowditch_ch...@hotmail.com:
On 26/06/2012 15:39, mehdi houshmand wrote:
   
Sorry, added [VOTE] to subject line... My bad
   
   
+1 from me. Good work Mehdi and Pete.
   
Chris
   
   
   
On 26 June 2012 15:38, mehdi houshmand med1...@gmail.com
mailto:med1...@gmail.com wrote:
   
Hi All,
   
I think we've got to the stage in the URI unification branch
where
it's ready to be merged into trunk (not into 1.1RC1). I know
there
have been proponents against the inclusion of this feature
and/or
those who are concerned the wider implications as it means FOP
has
fewer contingency methods when attempting file access. I'll
 try
and explain how we've addressed those concerns as well as some
of
the code improvements we've made.
   
- Syntactic URI fall-back mechanisms - if a URI is
 syntactically
erroneous i.e. contains white-space, \ instead of /, we do
some validation on to mitigate some of the common mistakes.
However, we don't allow for falling back to 'new File(.)' or
new URL(...).openStream() since these can obviously cause
clashes in a highly parallelised multi-tenant environment.
   
- Single FOP conf parse - Previously the renderer specific
regions
of the FOP conf was being parsed on every run. This is costly
 to
performance for the obvious reason, but as well as this, it
meant
that font auto-detection was having to be executed on every
 run.
The font-caching was created to mitigate some of those
performance
costs, however, caching the FOP conf makes much more sense. It
means we can get rid of the font-caching and don't have to to
worry about performance but it also allowed to do a lot of
 clean
up in the configuration packages. The renderer specific config
is
also lazy loaded such that it is only parsed when the
 respective
renderer is invoked, mitigating the one-off cost of parsing
 that
config.
   
- The environment profile - We've created an environment
 profile
that abstracts the system in which FOP is invoked. This allows
us
to programmatically enforce restrictions to, for example,
font-caching and auto-detection since users may want to
 control
this behaviour for any number of reasons.
   
- Improved URI 

Re: [VOTE] Merge Temp_URI_Unification

[Glenn Adams]

On Mon, Jul 2, 2012 at 7:25 AM, mehdi houshmand med1...@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.