Re: A proposal to change the configuration and deployment of FOP

2012-04-04 Thread mehdi houshmand
Hi Jeremias, I'll add my comments inline: > > First, I'd like to stress that I'm not putting out a veto here. I'm > just trying to take the position of an advocate to the FOP users who > might not all follow the development closely. > Yeah, I/we do appreciate your concerns, it's important for a

Re: A proposal to change the configuration and deployment of FOP

2012-04-04 Thread Alexios Giotis
On Apr 2, 2012, at 5:25 PM, mehdi houshmand wrote: > > The only thing I have left to say is that the system just wasn't designed for > what we're asking it to do now. When FopFactory was written, clouds were in > the sky and SaaS was a typo. For better or worse though, that's where the > indus

Re: A proposal to change the configuration and deployment of FOP

2012-04-03 Thread Glenn Adams
On Tue, Apr 3, 2012 at 5:26 PM, Martin Edge wrote: > Yes, if you changed IF on me I'd need to know. I embed postscript commands > in headers and page sequences. > > That said - if you are talking the java side of it versus the file format > itself that doesn't affect me (but of course it may other

Re: A proposal to change the configuration and deployment of FOP

2012-04-03 Thread Martin Edge
Yes, if you changed IF on me I'd need to know. I embed postscript commands in headers and page sequences. That said - if you are talking the java side of it versus the file format itself that doesn't affect me (but of course it may others) Thanks Martin --- Martin Edge ---

RE: A proposal to change the configuration and deployment of FOP

2012-04-03 Thread Marquart, Joshua D
inion, the upgrading page for each version is quite appropriately blatant. -Josh -Original Message- From: Jeremias Maerki [mailto:d...@jeremias-maerki.ch] Sent: Tuesday, April 03, 2012 3:36 PM To: fop-dev@xmlgraphics.apache.org Subject: Re: A proposal to change the configuration and deploym

Re: A proposal to change the configuration and deployment of FOP

2012-04-03 Thread Glenn Adams
On Tue, Apr 3, 2012 at 1:54 PM, Jeremias Maerki wrote: > Glenn, > I see the IF API as an advanced use case for FOP. I've realized from the > beginning that the IF might have to mature over time and that requires > changes. My main concern in the whole discussion is stability for the > large majori

Re: A proposal to change the configuration and deployment of FOP

2012-04-03 Thread Jeremias Maerki
Glenn, I see the IF API as an advanced use case for FOP. I've realized from the beginning that the IF might have to mature over time and that requires changes. My main concern in the whole discussion is stability for the large majority of FOP's users who just rely directly or indirecly (in the case

Re: A proposal to change the configuration and deployment of FOP

2012-04-03 Thread Jeremias Maerki
Thanks for the extensive explanation, Mehdi (and Chris)! First, I'd like to stress that I'm not putting out a veto here. I'm just trying to take the position of an advocate to the FOP users who might not all follow the development closely. Back on the technical side: A JAXP TransformerFactory is

Re: A proposal to change the configuration and deployment of FOP

2012-04-02 Thread mehdi houshmand
Hi Glenn, Firstly, although this is loosely related, can you try to keep the emails in the thread relevant, this is going to be a verbose thread so we don't want to add to the confusion. As for the public API, I don't believe IFPainter is part of the public API, but I'm not sure who does and doesn

Re: A proposal to change the configuration and deployment of FOP

2012-04-02 Thread Glenn Adams
On Mon, Apr 2, 2012 at 9:15 AM, Glenn Adams wrote: > On Wed, Mar 28, 2012 at 12:08 PM, Jeremias Maerki > wrote: > >> There must be a really, really good reason to change the frontmost >> public API of FOP in a backwards-incompatible way. Changing the API will >> cause considerable work for all u

Re: A proposal to change the configuration and deployment of FOP

2012-04-02 Thread Glenn Adams
On Wed, Mar 28, 2012 at 12:08 PM, Jeremias Maerki wrote: > There must be a really, really good reason to change the frontmost > public API of FOP in a backwards-incompatible way. Changing the API will > cause considerable work for all users when they upgrade. We must not do > that on a whim. > W

Re: A proposal to change the configuration and deployment of FOP

2012-04-02 Thread mehdi houshmand
Hi Jeremias/Chris, First thing first; I'll second Jeremias's suggestion and Chris in saying that this is definitely a major release. The best reason is because we're purposefully changing behaviour. FOP is currently very flexible in handling URIs, it has a lot of contingency mechanisms for falling

Re: A proposal to change the configuration and deployment of FOP

2012-04-02 Thread Chris Bowditch
On 01/04/2012 15:47, Jeremias Maerki wrote: Hi Jeremias, Thanks for your feedback. I'm answering in place of Peter who is on holiday this week. Thanks for elaborating, Peter. Your use of the term "deployment" is indeed rather unorthodox. When I read "deployment", I instantly think: http://en.w

Re: A proposal to change the configuration and deployment of FOP

2012-04-01 Thread Jeremias Maerki
Thanks for elaborating, Peter. Your use of the term "deployment" is indeed rather unorthodox. When I read "deployment", I instantly think: http://en.wikipedia.org/wiki/Software_deployment I'm afraid you still haven't convinced me of the necessity to break the public API even if, as you say, it's o

Re: A proposal to change the configuration and deployment of FOP

2012-03-30 Thread Peter Hancock
Hi Jeremias, Thanks for your feedback! On Wed, Mar 28, 2012 at 7:08 PM, Jeremias Maerki wrote: > Hi Peter, > > can you please explain what problem you're trying to solve? From the > Wiki pages I cannot derive that. And what do you mean by the separation > of configuration and deployment? I'

Re: A proposal to change the configuration and deployment of FOP

2012-03-28 Thread Alexios Giotis
Hi Peter, The public API could be improved but I also don't see in the wiki links a good reason to do so. It is expected to have a stable public API, once a project reaches a 1.0 version. Backwards incompatible changes are expected in a 2.0 version for methods/classes that have been deprecated.

Re: A proposal to change the configuration and deployment of FOP

2012-03-28 Thread Jeremias Maerki
Hi Peter, can you please explain what problem you're trying to solve? From the Wiki pages I cannot derive that. And what do you mean by the separation of configuration and deployment? I'm particularly clueless as to how an API affects deployment here. There must be a really, really good reason to