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....@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....@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@lists.osgeo.orghttps://
lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Best regards,
Dmitry
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
