edgar soldin wrote: > On 09.04.2013 05:32, Larry Reeder wrote: .... > > One clarification: my plugin doesn't directly load native libraries. It > > uses >> the sqlite JDBC libraries, which handle the loading spatialite and other >> sqllite >> extensions. > > what about the mysql, oracle, postgis support .. doesn't it need native libs > for > these?
No, they are using the server-client architecture and it is enough to have a JDBC client which is written in Java for taking care about connecting to the port where the service is and discussion with the database by using the correct protocol. SQLite is a different thing because there is no service to connect. The whole database engine is in the SQLite binaries. > >I also share some of the same concerns that Michaël mentioned, and think > that adding native libraries introduces risk and complexity: > > > > 1. A bug in the native libraries can cause the JVM to crash, taking down OJ > in the process (not just a stack trace but an outright crash. > > can happen > > > 3. Regarding the spatialite lib, you not only need to include the correct > version of that, but the correct versions of everything it depends on, > including proj, geos, sqlite, and others. > > of course. still the functionality is there, so why not leverage it? It is possible to leverage it in such a way that if one dependency it broken then nothing works. Let's not do it that way. > > 4. Adding all these libs would reproduce in native code much of what OJ > already does in Java. > > yes, it would blow up PLUS significantly. question is how much. i would make > it depending on that. This depends on what is baked in with Spatialite. The dll package made by Alesssandro (Mr. Spatialite) contains mostly everything that is possible (GEOS, Proj4, iconv, Excel read stuff) and those make 11 MB all together in 10 dll files. The SQLite JDBC driver which is compulsory makes 4 MB more. I found also another build here https://bitbucket.org/mayastudios/files/src/9c048c2e9fcb/sqlite/sqlite-3.7.15.2/win-x86?at=default Those two dll files (sqlite.dll and spatialite.dll) makeonly 5 MB together and they work OK with the DB Query plugin. GEOS and Proj4 are included in the spatialite.dll in this build https://bitbucket.org/mayastudios/spatialite-lib-windows I think that 9 or even 15 MB is not much for the coordinate system support alone. But I do not know where to get binaries for all Windows/Linux/Mac/32-bit/64-bit. I seems to be rather complicated to build Spatialite, especially for Windows. > > > > Larry: would you be willing to accept patches on the regard above? would > be a good opportunity to reuse a native lib loader that i created for the RXTX > using gps extension originally. > > > > > > Ede, I'm always open to new patches, I just don't think a native lib > > loader is >> needed due to SQLite JDBC handling the loading. > > what about the other db's mentioned above? also it would ease the use of > spatiallite as it could be found automagically and would not have to be > specified in the url. same would go for users deciding they wanted to use the > gdal lib support together with sqlite. If Spatialite is given in the URL then it is at least easy for the user to leave it out. I am not sure about what happens if loading of SQLite extension fails but I made a little test which suggests that if one part is missing then nothing works, not even standard functions which do not belong to the extension. Therefore user should also have a possibility to skip extensions. > also, i'd anyway like to enhance the support for loading native code in OJ > core. something along the lines that you just have to put it in > lib/native/<os>/<version>/<arch> or above if it works over several os > versions and the setting up of native lib paths goes away. > > > Finally, the main purpose of the DBQuery plugin is to provide a bridge >> between OJ and spatial databases that it might not support (if any now), as >> well as provide a way to submit ad-hoc queries that don't have or need >> backing tables to return features. While I'm glad my recent changes make it >> more useful for spatialite users, adding all the native libs to support >> spatialite >> would weigh it very heavily toward the spatialite side. If the main goal >> is to >> improve spatialite, perhaps a better approach is to build up the current >> sqlite/spatialite plugin to do so? >> >> i am no user, so i'd ask jukka. what do you think is the better starting >> point >> here? Myself I will for sure use Spatialite extension with Larry's plugin but I consider that the plugin is pretty good as it is and I would not like to pollute it much with extra decorations. -Jukka- > > ..ede > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced analytics > on semi-structured data. The platform includes APIs for building apps and a > phenomenal toolset for data science. Developers can use our toolset for > easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
