[gdal-dev] port/md5 cvs_MD5*

[Dmitry Baryshnikov]

In fact it was part of core of GDAL but hidden in WMS driver folder. The 
same or similar is in:

1. ogr/ogrsf_frmts/generic

2. ogr/ogrsf_frmts/geojson

What solution can be suitable here (I mean md5 case)?


Best regards,
     Dmitry

20.12.2017 17:19, Kurt Schwehr пишет:
> I have not looked in the wms code much, but my comment was not about adding
> an external dependency. It is about code quality in the core of GDAL.
>
> On Dec 20, 2017 6:07 AM, "Dmitry Baryshnikov" <bishop.dev at gmail.com> wrote:
>
>> Hi Kurt.
>>
>> The md5.cpp and md5.h were in frmst/wms driver folder. As I see from
>> header this files are not initially from GDAL project.
>>
>> I moved this files to port with minimum changes - only macros for suppress
>> Doxygen parsing.
>>
>> The motivation of this moving was:
>>
>> 1. md5 functions used in several drivers (WMS and WFS) and may be others
>> in future.
>>
>> 2. need API function to get the same md5 hash as used in WMS for
>> autotesting functionality.
>>
>> 3. downloading area of interest into the WMS file based cache by external
>> programs. May be some other utilization.
>>
>> I think ideally the OpenSSL MD5 functions must be using. But this will be
>> one more dependency. Do we need it?
>>
>>
>> Best regards,
>>      Dmitry
>>
>> 20.12.2017 16:43, Kurt Schwehr пишет:
>>
>> Hi all,
>>
>> Can we discuss cvs_MD5* from https://trac.osgeo.org/gdal/changeset/41086 ?
>>
>> I very much appreciate the work that bishop is doing and I hate to slow
>> down a contributor
>>
>> I am really worried about code like this going into GDAL, especially into
>> port/
>>
>> But my worries are:
>>
>> - this in no way conforms to other code in GDAL
>> - has the potential to collide with other code that imports this code
>> - it has a very awkward C style
>> - the commit message did not point to where it came from (at least it's not
>> hard to guess)
>> - the file naming is different than (most) of the rest of the directory
>> - and...
>>
>> Yes, we have other libraries included, but it seems like a road we don't
>> want to go down
>>
>> -kurt
>>
>>
>>
>>
>> _______________________________________________
>> gdal-dev mailing listgdal-dev at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>>
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>