[gdal-dev] port/md5 cvs_MD5*

[Dmitry Baryshnikov]

Will answer in letter body

20.12.2017 17:39, 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.
For example we have such method - char * OGRGeometry::exportToJson() const

In this method executed OGR_G_ExportToJson from 
ogr/ogrsf_frmts/geojson/ogrgeojsonwriter.cpp

So the core OGR using some code from GeoJSON driver.

The same way I can move md5 back to WMS and use it from port function 
CPLMD5String.

But I think ogr and gdal must use port (and port shouldn't depends on 
org or gcore, etc.),
also drivers can use ogr or gdal, but ogr and gdal shouldn't depends on 
some driver.

This is only my opinion.
>
> 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.
I'm not sure that Python produce the same hash than cvs_MD5*.
Also I'm not sure what in future they will be the same.
Finally not only Python use CPLMD5String - any program utilizing API may 
need the hash formed the same way as WMS/WFS does.
>
> 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
>>>>
>>>>
>

Best regards,
     Dmitry