[gdal-dev] port/md5 cvs_MD5*

[Dmitry Baryshnikov]

Hi Ari,

The pull request and discussion can be found here: 
https://github.com/OSGeo/gdal/pull/280

I cannot imagine that this improvements will affect something else. MD5 
used for cache paths initially, I only added some improvements for WMS 
cache size limits, expire time and split cache per dataset base (i.e. to 
delete cached files when dataset deletes).

What about your idea about common caching classes/functions - this is 
topic to discuss.

Best regards,
     Dmitry

21.12.2017 0:32, Ari Jolma пишет:
> My comments on this:
>
> 1) The MD5 function seems to be needed only(?) for the WMS cache and 
> probably also WFS. To me that highlights the need for some integration 
> work regarding caching in GDAL. I also implemented yet another caching 
> code for the WCS (without MD5). Looking at my $HOME/.gdal I see also 
> gmlas_xsd_cache and srs_cache.
>
> 2) This discussion thread also highlights the need to go towards more 
> pull request style development at least for bigger changes.
>
> Ari
>
>
> Kurt Schwehr kirjoitti 21.12.2017 klo 02:56:
>> Dmitry,
>>
>> Statements like this indicate a world of trouble:
>>
>> > 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.
>>
>> If you remove the swig and python stuff, move the CPLMD5String to 
>> cpl_md5.{cpp,h}, and follow Even's suggestions, I will be much 
>> happier with the change.  A C++ test would be good too. I'll be happy 
>> to do a quick fix up of a few things that I see in the md5 code once 
>> it is to that point.  I do think it is a good thing that there be md5 
>> support in port along with the existing sha{1,256} code.
>>
>> I see what you are saying about 
>> the OGRGeometry::exportTo{json,kml,gml}, but that doesn't (to me) 
>> support your argument.  My personal opinion is that GDAL would have 
>> been stronger if those had separate and not been a part of OGRGeometry.
>>
>> If there is a critical difference between CPLMD5String or a language 
>> and use case where md5 support in that language from GDAL is really 
>> required, you need to first document that issue.
>>
>> On Wed, Dec 20, 2017 at 7:46 AM, Dmitry Baryshnikov 
>> <bishop.dev at gmail.com <mailto:bishop.dev at gmail.com>> wrote:
>>
>>     Just the note that CPLMD5String not only for Python, but any other
>>     API clients: C/C++, Java, Perl, etc.
>>
>>     But, I agree, it can be easily removed.
>>
>>     Best regards,
>>         Dmitry
>>
>>     20.12.2017 18 <tel:20.12.2017%2018>:35, Even Rouault пишет:
>>
>>                 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*.
>>
>>         I do hope they return the same thing. MD5 is a standardized
>>         algorithm:
>>         https://tools.ietf.org/html/rfc1321
>>         <https://tools.ietf.org/html/rfc1321>
>>
>>         I'm not sure we really need to expose it our CPL MD5 through
>>         Python.
>>
>>
>>     _______________________________________________
>>     gdal-dev mailing list
>>     gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
>>     https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>     <https://lists.osgeo.org/mailman/listinfo/gdal-dev>
>>
>>
>>
>>
>> -- 
>> -- 
>> http://schwehr.org
>>
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://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

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