[PROJ] Motion: Accept RFC4 (PROJ JNI Overhaul)

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[PROJ] Motion: Accept RFC4 (PROJ JNI Overhaul)

Kristian Evers-2

RFC4 about updating the Java bindings for PROJ has now been up for review

for a week [0]. Some clarification has been given in the comments on GitHub

but no changes has been made to the actual RFC.

 

I hereby motion that the RFC is accepted. I’ll start with my +1.

 

/Kristian

 

[0] https://github.com/OSGeo/PROJ/pull/1551


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Motion: Accept RFC4 (PROJ JNI Overhaul)

Kristian Evers-2

Don’t worry, I seem to have submitted the draft in prime vacationing time. Howard has also just caught up today and provided some useful insights which may result in changes to the RFC. Looking forward to your input!

 

/Kristian

 

From: Kurt Schwehr <[hidden email]>
Sent: 15. juli 2019 16:15
To: Kristian Evers <[hidden email]>
Subject: Re: [PROJ] Motion: Accept RFC4 (PROJ JNI Overhaul)

 

Hey,. I will read the RFC in the next couple hours.  Sorry for not being up on these things.

 

On Mon, Jul 15, 2019, 4:43 AM Kristian Evers <[hidden email]> wrote:

RFC4 about updating the Java bindings for PROJ has now been up for review

for a week [0]. Some clarification has been given in the comments on GitHub

but no changes has been made to the actual RFC.

 

I hereby motion that the RFC is accepted. I’ll start with my +1.

 

/Kristian

 

[0] https://github.com/OSGeo/PROJ/pull/1551

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Motion: Accept RFC4 (PROJ JNI Overhaul)

Kurt Schwehr-2
+1 Kurt

And +1 to all who comment in the PR.  I'll add my reason for the +1 in the PR.

On Mon, Jul 15, 2019 at 7:20 AM Kristian Evers <[hidden email]> wrote:

Don’t worry, I seem to have submitted the draft in prime vacationing time. Howard has also just caught up today and provided some useful insights which may result in changes to the RFC. Looking forward to your input!

 

/Kristian

 

From: Kurt Schwehr <[hidden email]>
Sent: 15. juli 2019 16:15
To: Kristian Evers <[hidden email]>
Subject: Re: [PROJ] Motion: Accept RFC4 (PROJ JNI Overhaul)

 

Hey,. I will read the RFC in the next couple hours.  Sorry for not being up on these things.

 

On Mon, Jul 15, 2019, 4:43 AM Kristian Evers <[hidden email]> wrote:

RFC4 about updating the Java bindings for PROJ has now been up for review

for a week [0]. Some clarification has been given in the comments on GitHub

but no changes has been made to the actual RFC.

 

I hereby motion that the RFC is accepted. I’ll start with my +1.

 

/Kristian

 

[0] https://github.com/OSGeo/PROJ/pull/1551

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Motion: Accept RFC4 (PROJ JNI Overhaul)

Even Rouault-2
In reply to this post by Kristian Evers-2
Hi,

I vote +0

- I'm supportive of having rejuvenated Java bindings.
- I won't likely be a user / contributor to them myself.
- I've some doubts that having them in OSGeo/PROJ repo is the best thing, but
as the RFC mentions the use of only public PROJ C or C++ API, it could be
possible to exfiltrate them if needed.

Ah, the RFC doesn't mention licensing consideration. I assume the code will be
under the PROJ X/MIT license ? At least, the native part, especially if it is
bundled into libproj.

Other nitpicking detail. The RFC currently mentions: "The PROJ Java Native
Interface exposes the ``proj_api.h`". This is not actually true. src/
jniproj.cpp includes proj_internal.h and uses functions that were part of
former projects.h

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Motion: Accept RFC4 (PROJ JNI Overhaul)

Martin Desruisseaux-3
Le 17/07/2019 à 11:15, Even Rouault a écrit :

> Ah, the RFC doesn't mention licensing consideration. I assume the code
> will be under the PROJ X/MIT license ?
>
I would said yes, both the native and Java parts.

    Martin


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Motion: Accept RFC4 (PROJ JNI Overhaul)

Howard Butler-3
In reply to this post by Even Rouault-2
I'm -0 for the same reasons as Even states. If the Java bindings weren't already in PROJ for 15 years, I would be vetoing, but the ship has sailed. The updated Java bindings should be architected in such a way that if they stale again in 5-10 years that they can be ejected out of the tree into their own repository.

I am not supportive of any other language bindings coming into the PROJ source tree. We do not want to bless any bindings as official because this is likely to squash any innovation that might go on. This action also has a bad side effect of tying the release of the bindings to the release of the main library, which may or may not be a good idea. These things are separate and should evolve and be maintained separately.

Howard

> On Jul 17, 2019, at 4:15 AM, Even Rouault <[hidden email]> wrote:
>
> Hi,
>
> I vote +0
>
> - I'm supportive of having rejuvenated Java bindings.
> - I won't likely be a user / contributor to them myself.
> - I've some doubts that having them in OSGeo/PROJ repo is the best thing, but
> as the RFC mentions the use of only public PROJ C or C++ API, it could be
> possible to exfiltrate them if needed.
>
> Ah, the RFC doesn't mention licensing consideration. I assume the code will be
> under the PROJ X/MIT license ? At least, the native part, especially if it is
> bundled into libproj.
>
> Other nitpicking detail. The RFC currently mentions: "The PROJ Java Native
> Interface exposes the ``proj_api.h`". This is not actually true. src/
> jniproj.cpp includes proj_internal.h and uses functions that were part of
> former projects.h
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _______________________________________________
> PROJ mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/proj

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Motion: Accept RFC4 (PROJ JNI Overhaul)

Martin Desruisseaux-3
Le 17/07/2019 à 16:28, Howard Butler a écrit :
We do not want to bless any bindings as official because this is likely to squash any innovation that might go on.

I think there is two parts:

  1. Defining an API in another language.
  2. Providing a binding between PROJ and that other API.

Current PROJ and GDAL bindings merged those two parts, basically reflecting the PROJ/GDAL API in the other language. I agree that other communities are in better position for defining an API in their language. By keeping part #1 out of this RFC and hosting only part #2 on the PROJ repository, I think the situation become more similar to PostgreSQL project providing a JDBC driver, not an API for accessing databases.

    Martin



_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Motion: Accept RFC4 (PROJ JNI Overhaul)

Greg Troxel-2
In reply to this post by Howard Butler-3
I'm not PSC of course, but with a lot of +0 sentiment (which I interpret
as "I don't really like this, but I don't feel like it's reasonable to
object"), it seems like it might be a good time to have the java binding
in it's own package.

From a packaging system point of view, separate is better, as it would
be crazy to require java to be installed to build the basic proj
package, and thus you end up building a proj package and then a
proj-java package.  If the java bindings are in a subdir and have their
own entirely separate build system (such that building proj doesn't
build them, and building the java bindings uses the installed proj and
doesn't build it locally), that's not really a problem, but it then also
doesn't really help to have them in the same source tarball.

So were I PSC, I'd be inclined to -1 and +1 in favor of "put this in a
separate repo".   That's not meant to be criticism of the code or java,
just a strong bias to having separable things separate.


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Motion: Accept RFC4 (PROJ JNI Overhaul)

Kristian Evers-2


> On 17 Jul 2019, at 17:02, Greg Troxel <[hidden email]> wrote:
>
> I'm not PSC of course, but with a lot of +0 sentiment (which I interpret
> as "I don't really like this, but I don't feel like it's reasonable to
> object"), it seems like it might be a good time to have the java binding
> in it's own package.
>

This is exactly how I am reading things as well. Thanks for putting it in
writing, Greg.

I am withdrawing the RFC and will instead work towards providing a
Java interface for PROJ in a stand-alone repository. Exactly where is
yet to be decided. Maybe as part of the OSGeo GitHub organisation?

Thanks to everyone for the feedback on this RFC. Many of the comments
we’ve received are still valid for a stand-alone package and will definitely
help improve these new bindings.

As for the current Java bindings in the PROJ repository, I would say
that the logical extension to this debate is that they will have to be
removed in the near future. More on that later.

/Kristian

> From a packaging system point of view, separate is better, as it would
> be crazy to require java to be installed to build the basic proj
> package, and thus you end up building a proj package and then a
> proj-java package.  If the java bindings are in a subdir and have their
> own entirely separate build system (such that building proj doesn't
> build them, and building the java bindings uses the installed proj and
> doesn't build it locally), that's not really a problem, but it then also
> doesn't really help to have them in the same source tarball.
>
> So were I PSC, I'd be inclined to -1 and +1 in favor of "put this in a
> separate repo".   That's not meant to be criticism of the code or java,
> just a strong bias to having separable things separate.
>
>
> _______________________________________________
> PROJ mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/proj

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj