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
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
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
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
---
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
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
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
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
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
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
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
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
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
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
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'
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.
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
Hello,
As part of our work addressing URI resolution in FOP [1], Mehdi and
myself have been considering making changes to the configuration and
deployment of FOP. Our proposal will introduce breaking changes to
the public API that will affect code that embeds FOP. Please review
our proposal [2]
18 matches
Mail list logo