Re: [!! SPAM] Re: svn commit: r713747 [1/4] - in /xmlgraphics/fop/branches/Temp_AFPGOCAResources/src: documentation/content/xdocs/trunk/ java/META-INF/services/ java/org/apache/fop/afp/ java/org/apache/fop/afp/fonts/ java/org/apache/fop/afp/goca/ java/org/apache/fop/afp...

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

Adrian Cumiskey wrote:

> Jeremias,

Adrian,

> 
> Jeremias Maerki wrote:
> 
>>> I'm sure if such a person existed and they wrote their own FOP 
>>> plug-in they could very easily fix a very small compatibility issue 
>>> such as this.
>>
>>
>> Again: it's not the fix that is the problem. It is about
>> backwards-compatibility and that's an issue mostly for users and release
>> managers. Developers have an easy life. Imagine what would happen if
>> Linus Torvalds would constantly change the API for low-level drivers or
>> if Sun would simply change APIs in their Java class library without
>> respecting backwards compatibility.
> 
> 
> I didn't make a change to a low-level driver used by millions.  I made a 
> change to one method signature of one interface that affected one 
> external package used by FOP that you host externally on your own 
> website.  I'm sorry that this change meant a small amount of 
> work/support overhead for you, but you are losing perspective here.

The point here isn't the affect of the change but the way you went about 
it, i.e. you just committed it and didn't tell anyway one about it, we 
had to find out for ourselves.

> 
>>>>> I have included the simple 2 line patch file for 
>>>>> src/java/org/apache/fop/render/pdf/pdfbox/PDFBoxPDFImageHandler.java.  
>>>>> Apologies if this creates a little more work for you.
>>>>
>>>> Your patch has one problem: it kills backwards-compatibility for FOP
>>>> 0.95. I won't delete the old method so this whole thing will still work
>>>> with 0.95.
>>>
>>> I don't see how this would at all affect 0.95 compatibility.  You 
>>> already provide a cersion 1.2
>>> (http://www.jeremias-maerki.ch/download/fop/pdf-images) which will 
>>> work just fine for 0.95
>>> installations - so no change there.  And you also already provide a 
>>> version 1.1a (from rev 611768 or later), so all that needs to be done 
>>> once the Temp_AFPGOCAResources branch is merged back into trunk is 
>>> release a new trunk version with the 2 line patch applied.
>>
>>
>> Yeah, and after your logic I'll continue to play that game indefinitely.
>> Each time we release a new FOP, I have to update my plug-in. That's not
>> my idea of software development.
> 
> 
> You know full well that this situation is not to be expected, this was 
> just an exception.  My idea of software development doesn't involve 
> spending lots of time trying to score points off each other on a mailing 
> list over quite small issues.

I don't think anyone is trying to score points here. We are just trying 
to find out the underlying reasons for the change to the interface. So 
far you've not given us a good technical reason. The reason you did give 
  about the Image handler in the AFP Renderer needing to support 
multiple image types has been proven to be unnecessary (see Jeremias' 
reply to the Merge branch thread)

> 
>>>> The necessary changes in my plug-in are negligible. What isn't is the
>>>> time I'll spend documenting which version of the plug-in the users have
>>>> to select for which FOP version. Add to that time I spend on answering
>>>> the questions of the people who don't RTFM.
>>>
>>> I sympathize, users can be demanding even when you give of your time 
>>> freely :).
>>>
>>>> I wonder if you've spent one second thinking about
>>>> backwards-compatibility before changing the PDFImageHandler interface.
>>>
>>> Quite simply I wasn't aware that your external pdf images package 
>>> touched upon this interface.  Its not part of the FOP code base.  I 
>>> will continue to always want what is best for the health of the 
>>> project, I find your comment both unnecessarily rude and disrespectful.
>>
>>
>> It doesn't really matter if I have an external implementation of that
>> interface or not. The interface was designed as a service provider
>> interface with dynamic registration. That automatically turns it into an
>> external interface for FOP which needs to be treated with care.
>>
>> The PDF renderer doesn't profit from the changes you made. It just
>> breaks the already existing plug-ins. You've had an idea for the image
>> handler plug-ins for the AFP Renderer and you wanted to reuse the
>> registry part. And that's what affects the PDF part. The name clash in
>> the IF branch is another story. That one is not even so important.
> 
> 
> I never claimed that the PDF renderer would profit did I?  But other 
> parts of FOP certainly could.
> 
>> Change happens, yes, improvements happen, too, but the "after me the
>> Flood" mentality makes my blood boil.
> 
> 
> I have no such mentality, you boil your own blood.  I fail to understand
> why you continue to blow up small points out of all proportion and 
> attack me in this way.  I have worked very hard to improve our AFP 
> support and now you try to provoke me and make things ugly.

Let's try to stay calm. No one is attacking anyone. We are simply some 
intellectual's trying to understand each other's point of view. 
Sometimes e-mail is not the best way to do this as it is a very cold 
form of communication. I don't mean any offence by my questions and I'm 
certain Jeremias' means none by his.

Regards,

Chris

> 
> Adrian.
> 
>