Dear Gabriel,

I went through your proposal; I will start with some comments about the
*motivation* section:

   - *The persistence abstractions are powered by Google's Generic DAO
   Framework, which is not maintained since years ago*
      - This refactoring was already completed and working, as reported in
      this issue:
         - JDK11 compatibility #128
         <https://github.com/geoserver/geofence/issues/128> [1]
      - All the GenericDAO constructs were ported to Hibernate’s criteria
      and to some newly created classes to reduce the impact on the
existing code
      as much as possible.
   - *The REST APIs exposed by GeoFence's standalone server application,
   and the GeoFence embedded engine in GeoServer, have some differences, which
   makes it hard to use a REST client interchangeably.*
      - When the REST APIs were reimplemented in the embedded configuration
      (in the geofence-server module), they did not follow the detailed
      documentation available at GeoFence REST API
      <https://github.com/geoserver/geofence/wiki/GeoFence-REST-API> [2] ,
      that was followed in the initial (standalone) implementation. *I
      would not create a third API, but would stick to the existing
one: breaking
      backwards compatibility is something we try very hard not to do in
      GeoServer, since there are deployed systems depending on it that would
      break on upgrade.*

Regarding the other points, it’s great getting rid of the older libraries
(we had to revive the old Hibernate Spatial in order to keep up with the
JTS upgrades – see https://github.com/geosolutions-it/hibernate-spatial).
So, apart from the notes above, I’m good with the various motivations and
points in the proposal, because they aim to get rid of older unmaintained
libraries and to keep the libs aligned with the ones used in GeoServer.

That said, I’m quite concerned with the modules refactoring:

   - *They are not strictly needed and motivated by the previous points. *
   - They will likely make it difficult to review and functionally validate.
   - They may introduce further issues, along with the potential ones
   caused by the already big library upgrade shock.
   - They may be a blocker for the current maintainers to keep up the work
   and to respond quickly to the issues that will pop up, especially in the
   first times it will be released.


*My proposal is to split the current proposed work in two phases:*

   - A first GSIP (and PR) focused on the points listed in the
   motivations/proposal, that is an *upgrade of the libraries*, and partial
   rewriting of the code/configurations strictly needed to make the new libs
   work. That GSIP would be reviewed, tested, and accepted quite quickly,
   because this is a much-needed improvement with a well-defined scope, and
   the current maintainer would know the existing dependencies between modules.
   - A second GSIP about the *module refactoring*, that IMHO should be
   agreed upon by the developers’ community (and in particular module
   maintainers) in advance, to explore the possible alternative design, and
   find one that both parties agree upon. It would need more time to be
   investigated, tested, discussed, and in the end adopted and would give time
   to the other devs to get accustomed to it.


Looking forward in reading your feedback.

   Cheers,
   Emanuele


[1] https://github.com/geoserver/geofence/issues/128
[2] https://github.com/geoserver/geofence/wiki/GeoFence-REST-API

On Wed, Mar 8, 2023 at 3:35 AM Gabriel Roldan <gabriel.rol...@camptocamp.com>
wrote:

> Hi list,
>
> I've just created a GSIP (216) with a proposal to make several
> improvements to GeoFence.
>
> Please see https://github.com/geoserver/geoserver/wiki/GSIP-216 for
> details.
>
> *camptocamp*
> INNOVATIVE SOLUTIONS
> BY OPEN SOURCE EXPERTS
>
> *Gabriel Roldán*
> Geospatial Developer
>
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>


-- 
Regards,
Emanuele Tajariol
==
GeoServer Professional Services from the experts!
Visit http://bit.ly/gs-services-us for more information.
==

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions Group
mobile: +39 347 7895230
office: +39 0584 962313
fax:      +39 0584 1660272

https://www.geosolutionsgroup.com/
http://twitter.com/geosolutions_it
-------------------------------------------------------

Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
precisa che ogni circostanza inerente alla presente email (il suo
contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
operazione è illecita. Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to which it is
addressed and may contain information that is privileged, confidential or
otherwise protected from disclosure. We remind that - as provided by
European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
e-mail or the information herein by anyone other than the intended
recipient is prohibited. If you have received this email by mistake, please
notify us immediately by telephone or e-mail.
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to