[gdal-dev] image-io extension

Sun Dec 12 20:46:43 EST 2010

Hi

On Mon, Dec 13, 2010 at 2:33 AM, Simone Giannecchini
<simone.giannecchini at geo-solutions.it> wrote:
> Ciao Even,
> I am neither trying to cut it short nor I was anyhow offended by your
> response but you are email
> is drawing is essence from a few  misunderstandings which I would like
> to clarify before this thread takes more time/space:
>
> -1- Viji is trying to package the development version of imageio-ext,
> which is not (atm at least) used in any official version of geotools
> and/or geoserver. He is actually playing with the trunk of
> imageio-ext..
> -2- I never intended to propose anything to be committed in GDAL at
> this moment, especially the patch that Viji has been looking at. As we
> have done in the past we will try to propose changes only when they
> are really needed
> and of interest for the community
> -3- Our goals in the short/mid terms with regards to the GDAL JNI
> bindings are confined to a user standpoint, with the possibility to
> propose few isolated patches as we have done in the past. We do not
> foresee resources for broader involvement.
>
> Summarising if Viji wants to package imageio-ext he is looking at the
> wrong version. 1.0.8 should work with gdal 1.4.5 as it is
> (mainstream?). I will have daniele confirm this tomorrow.

The fedora releases already have a much higher mainstream stable
version of GDAL, 1.7.x. I am afraid  that we cannot downgrade this to
have the image-io extension support.

Thanks
Viji
>
> Ciao,
> Simone.
> -------------------------------------------------------
> Ing. Simone Giannecchini
> GeoSolutions S.A.S.
> Founder
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: +39 0584962313
> fax:      +39 0584962313
> mob:    +39 333 8128928
>
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.linkedin.com/in/simonegiannecchini
> http://twitter.com/simogeo
>
> -------------------------------------------------------
>
>
>
> On Sat, Dec 11, 2010 at 12:41 AM, Even Rouault
> <even.rouault at mines-paris.org> wrote:
>> Le vendredi 10 décembre 2010 10:27:49, Simone Giannecchini a écrit :
>>> Ciao Even,
>>> I have asked daniele to make those changes (which have not been reviewed
>>> yet) in order to move away from the explicit usage of Vector and HashTable
>>> in method signatures in favour of using the respective interfaces (List
>>> and Map). Daniele can add more as needed...
>>
>> Simone,
>>
>> I can understand that you don't like using Vector or Hashtable in the API you
>> expose in imageio-ext, but you can also understand that it doesn't make a very
>> compelling reason to take your changes in the hope that they also fit the needs
>> of other users of the GDAL Java bindings.
>>
>> You could certainly convert the Vector into an ArrayList on your side and
>> "hide" that. Not ideal, but there's no technical obstacle.
>>
>> The GDAL Python bindings are also well-known for not being very "pythonish" by
>> some aspects (and some of those aspects can be sometimes very very painful !),
>> but it doesn't prevent them from being used successfully by a pretty
>> impressive amount of people.
>>
>>>
>>> As you mentioned this change can break old code, but it should
>>> make the java bindings more ... javaish :).
>>
>> I'd note that what is "javaish" or not is subject to trends that evolve over
>> time. Sometimes it is not bad to wait for the dust to settle ;-)
>>
>> And concerning :
>>
>>> On the other hand GDAL is well known for the rock solid stability of
>>> its API
>>
>> Indeed, I prefer that the bindings are stable (and sometimes expose rough
>> corners due to past choices). Being "javaish" isn't an aim per se.
>>
>>> but yeah this "instability" would apply only to the Java
>>> bindings and would follow a well known practice. """
>>
>> I respectfully disagree with you on this. For example, most API of the
>> standard Java library dating back to the Java 1.0 era haven't been removed in
>> Java 1.6. And by the way, neither
>> http://download.oracle.com/javase/6/docs/api/java/util/Vector.html nor
>> http://download.oracle.com/javase/6/docs/api/java/util/Hashtable.html mention
>> those 2 to be deprecated at all ;-)
>> Now, you'll certainly find other Java projects that might have different habits
>> of course.
>>
>> Let's be realistic : interface breakage can happen sometimes. But IMHO the
>> reasons must be very compelling (totally broken/unusable interface). And I'd
>> expect a consensus on this, or at least support from a majority of users.
>>
>>>
>>> We have other changes in the queue which we might submit to your review
>>> early next year, but this is another topic...
>>
>> If you wish that your changes to be integrated back into GDAL, I'm afraid this
>> isn't the best way to proceed. It is not very efficient and enjoyable to review
>> a code dump without prior discussion about its rationale and main orientations
>> (especially when it involves API breakage). Basically, I'm just recalling a
>> best-practice for collaboration with any FOSS project...
>>
>>>
>>>
>>> Viji , I don't think you need to use the patch you are referring to since
>>> that is needed for imageio-ext 1.1 which has not been released yet.
>>
>> I'm afraid that the packagers of imageio-ext 1.1 will face difficult
>> alternatives if your patch is still needed but not applied in upstream GDAL :
>> - Applying your patch and thus forking from upstream GDAL as far as the GDAL
>> Java API is concerned ? --> Most Linux distro (including Fedora unless I'm
>> wrong) have a policy to stick to upstream as much as possible and only patch
>> for serious reasons.
>> - Applying a patch to imageio-ext to make it work with upstream GDAL ?
>> Unlikely for the same reason as above and why would they make that effort
>> instead of upstream imageio-ext ?
>> - Finding a way to have a specific version of the patched GDAL Java bindings
>> only used by imageio-ext ? Technically possible I guess by "duplicating" the
>> java bindings (both the gdal.jar + the *jni.so) and embedding a specific
>> version in imageio-ext package. But then, you will have to make sure they
>> won't conflict in case someone wants to use both imageio-ext and "official" GDAL
>> java bindings. I also doubt that a packager would want to go into that.
>>
>>
>> Best regards,
>>
>> Even
>>
>>>
>>> Ciao,
>>> Simone.
>>> -------------------------------------------------------
>>> Ing. Simone Giannecchini
>>> GeoSolutions S.A.S.
>>> Founder
>>>
>>> Via Poggio alle Viti 1187
>>> 55054  Massarosa (LU)
>>> Italy
>>>
>>> phone: +39 0584962313
>>> fax:      +39 0584962313
>>> mob:    +39 333 8128928
>>>
>>>
>>> http://www.geo-solutions.it
>>> http://geo-solutions.blogspot.com/
>>> http://www.linkedin.com/in/simonegiannecchini
>>> http://twitter.com/simogeo
>>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>