[gdal-dev] port/md5 cvs_MD5*

[Kurt Schwehr]

My personal opinion...

It was not in fact in the core of GDAL for all users.  My primary
environment does not include the WMS *driver*.  My take is that only the
memory and gtiff raster drivers are really required for GDAL (vector, I'm
not so sure).

What do you mean by the same or similar for generic and geojson?  And
because something isn't great elsewhere, that does not mean we want to
introduce more similar code that is hard to impossible to opt out of.

Dmitry's question about a reasonable solution is a good one (if you buy my
being seriously uncomfortable with cvs_MD5*).  Possibilities include:

- Make everything from md5.cpp and md5.h be internal to md5.cpp (aka static
or inline) and move CPLMD5String to md5.{cpp,h} at least keeping the
trouble localize
- Refactor md5 to be cleaner
- Reimplement md5 hashing for gdal
- Find some other code that is license compatible that is cleaner

And why are you exposing this to python?  Python has md5 hashing already
built in.

Can others please weigh in?

On Wed, Dec 20, 2017 at 6:25 AM, Dmitry Baryshnikov <bishop.dev at gmail.com>
wrote:

> 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
>>>
>>>
>


-- 
--
http://schwehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20171220/f8c3c282/attachment.html>