<div dir="ltr"><div><span style="font-size:12.8px">My personal opinion...</span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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).</span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div>Dmitry's question about a reasonable solution is a good one (if you buy my being seriously uncomfortable with cvs_MD5*). Possibilities include:</div><div><br></div><div>- 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</div><div>- Refactor md5 to be cleaner</div><div>- Reimplement md5 hashing for gdal</div><div>- Find some other code that is license compatible that is cleaner</div><div><br></div><div>And why are you exposing this to python? Python has md5 hashing already built in.</div><div><br></div><div>Can others please weigh in? <br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 20, 2017 at 6:25 AM, Dmitry Baryshnikov <span dir="ltr"><<a href="mailto:bishop.dev@gmail.com" target="_blank">bishop.dev@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In fact it was part of core of GDAL but hidden in WMS driver folder. The same or similar is in:<br>
<br>
1. ogr/ogrsf_frmts/generic<br>
<br>
2. ogr/ogrsf_frmts/geojson<br>
<br>
What solution can be suitable here (I mean md5 case)?<br>
<br>
<br>
Best regards,<br>
Dmitry<br>
<br>
<a href="tel:20.12.2017%2017" value="+12012201717" target="_blank">20.12.2017 17</a>:19, Kurt Schwehr пишет:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
I have not looked in the wms code much, but my comment was not about adding<br>
an external dependency. It is about code quality in the core of GDAL.<br>
<br>
On Dec 20, 2017 6:07 AM, "Dmitry Baryshnikov" <<a href="mailto:bishop.dev@gmail.com" target="_blank">bishop.dev@gmail.com</a>> wrote:<br>
<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Hi Kurt.<br>
<br>
The md5.cpp and md5.h were in frmst/wms driver folder. As I see from<br>
header this files are not initially from GDAL project.<br>
<br>
I moved this files to port with minimum changes - only macros for suppress<br>
Doxygen parsing.<br>
<br>
The motivation of this moving was:<br>
<br>
1. md5 functions used in several drivers (WMS and WFS) and may be others<br>
in future.<br>
<br>
2. need API function to get the same md5 hash as used in WMS for<br>
autotesting functionality.<br>
<br>
3. downloading area of interest into the WMS file based cache by external<br>
programs. May be some other utilization.<br>
<br>
I think ideally the OpenSSL MD5 functions must be using. But this will be<br>
one more dependency. Do we need it?<br>
<br>
<br>
Best regards,<br>
Dmitry<br>
<br>
<a href="tel:20.12.2017%2016" value="+12012201716" target="_blank">20.12.2017 16</a>:43, Kurt Schwehr пишет:<br>
<br>
Hi all,<br>
<br>
Can we discuss cvs_MD5* from <a href="https://trac.osgeo.org/gdal/changeset/41086" rel="noreferrer" target="_blank">https://trac.osgeo.org/gdal/ch<wbr>angeset/41086</a> ?<br>
<br>
I very much appreciate the work that bishop is doing and I hate to slow<br>
down a contributor<br>
<br>
I am really worried about code like this going into GDAL, especially into<br>
port/<br>
<br>
But my worries are:<br>
<br>
- this in no way conforms to other code in GDAL<br>
- has the potential to collide with other code that imports this code<br>
- it has a very awkward C style<br>
- the commit message did not point to where it came from (at least it's not<br>
hard to guess)<br>
- the file naming is different than (most) of the rest of the directory<br>
- and...<br>
<br>
Yes, we have other libraries included, but it seems like a road we don't<br>
want to go down<br>
<br>
-kurt<br>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br></div></div>
gdal-dev mailing listgdal-dev@lists.osgeo.orght<wbr>tps://<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">lists.osgeo.org/mailman/<wbr>listinfo/gdal-dev</a><span class=""><br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailma<wbr>n/listinfo/gdal-dev</a><br>
<br>
</span></blockquote></blockquote>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--<div><a href="http://schwehr.org" target="_blank">http://schwehr.org</a></div></div>
</div>