Update to GSIP with additional details, such as adding a repo. Personally I would like these other geoserver repos to match geosever release cycle from a QA standpoint.
On Thu, Mar 16, 2023 at 7:58 AM Gabriel Roldan < gabriel.rol...@camptocamp.com> wrote: > Hi Andrea, Emanuele, and all. > > Thanks for this counter-proposal. It makes a lot of sense, and at > Camptocamp we just met and decided it's a good way forward. > > The project will be called GeoServer ACL, as in Access Control List. > > It will have a somewhat more limited scope than GeoFence, at least > initially, > focusing only on a separate service, not an embedded engine. > > Therefore, we need to fine tune a couple aspects. > > First and foremost, we need a home for it. It could be as part of > geoserver-cloud's codebase, > but it'd be so much better if we can be granted a /geoserver/geoserver-acl > github repository. > > Additionally we'll need to be able to deploy artifacts to maven, so the > community > module can depend on them. > > Do you think those two requests are acceptable? How can we proceed? is a > GSIP > required to create a sibling project under github's /geoserver > organization? > > Best regards, > *camptocamp* > INNOVATIVE SOLUTIONS > BY OPEN SOURCE EXPERTS > > *Gabriel Roldan* > Geospatial Developer > > > > On Mon, Mar 13, 2023 at 12:14 PM Andrea Aime < > andrea.a...@geosolutionsgroup.com> wrote: > >> Hi Gabriel, >> I’m going to start briefly and do what I haven’t done in ages: cast a -1 >> on the proposal, but with an alternative proposal that will allow you to >> retain all your existing work. >> >> Our community has had, over the years, a strong “talk first” policy. It >> means that one should discuss the design of a major change before doing >> actual work. This has precedent, for example it’s what I did in 2013, when >> I proposed to rewrite the CSS styling engine in Java >> <https://sourceforge.net/p/geoserver/mailman/geoserver-devel/thread/CA%2BnxMTvgAPO5rno80eF47%2BFmcJqeFPRSUL7Suf63k%3DSWEeU%3DZA%40mail.gmail.com/#msg30912716> >> (hard lesson learned there). >> >> Another bit that is quite relevant, is who is in control of the module: >> the PSC is the maintainer of all core modules, but extensions modules have >> a dedicated maintainer that controls the module. In this case, that’s >> Emanuele. While for a situation like this it’s great to have a document >> that details the proposed changes, I believe the PSC role is mostly a >> consultation. The rules are not clear here, I’m open to discussion. >> >> There are also practical aspects that make this rewrite a no go; they are >> not technical, but relate to pre-existing knowledge, availability of time >> and money. Maintenance of a module requires few things these days: being >> ready to review changes made by third parties, evaluate bug reports, and >> answer questions on the user list, on a “as time allows” basis. This can be >> done leveraging knowledge of how the module works. >> >> The fork is reshuffling the entire code base, and introducing a number of >> libraries that are not part of the existing GeoServer dependencies. Picking >> up all these new libraries is problematic for the community at large, >> because it increases the number of bits the developers have to be familiar >> with, and makes the review of changes even harder, because one would have >> to get up to speed with them before even starting to look at the code. >> >> Even assuming in blind faith that we could catch up later, it would still >> mean we have no way to review the changes in the short term (too much >> effort combined required to go and learn what we need, and then review the >> full rewrite). >> So, where to go from here? Where you are going, we simply cannot follow. >> >> We kindly ask you to retain all your work, and give it a different name: >> let’s call it GING for now (GING Is Not GeoFence). >> The following points are very important for us: >> >> - GING is not an “upgrade” to GeoFence, but a fork of it, that users >> can migrate to. >> - GING is not endorsed by GeoSolutions, but has, at the beginning, >> Gabriel Roldan as the sole maintainer. >> - GING starts as a new community module and works its way up to >> extension status like any other module (including Geofence >> <https://github.com/geoserver/geoserver/wiki/GSIP-164>) did. >> >> There is a number of advantages going this way: >> >> - Gabriel does not lose the large work investment in his fork, and >> gets a module that he’ll “be in charge of project maintenance for these >> customers for the foreseeable future” and will get a “codebase that's >> closer to pleasure to work on than to a hassle”. >> - There is no longer reason to carry around baggage, Gabriel can drop >> the other REST APIs and just keep the newer one. >> - The H2 dependency is no longer a problem, it can be dropped right >> away. >> - Gabriel still gets documentation and UI that he can adapt to the >> “GING” name, without having to recreate all of that from scratch. >> - The developer community avoids a fight, and the user community gets >> two alternative security subsystems that they can choose from based on the >> functionality and level of support they get from their respective >> maintainers. >> >> Finally, I’m not here saying that GeoSolutions will go with GeoFence in >> the longer term. It might well be that eventually the two end up >> converging, or that one eventually loses steam and dies and we end up all >> working on the same module. But in the short to medium term (e.g., the year >> to come), the direction proposed by Gabriel is not working for us. At the >> same time, the existing GeoFence code is not working for him, Emanuele has >> made a counter-proposal that has been rejected (or so I read the answer). >> Thus, it’s best to take two separate ways, while still working among the >> same community, leveraging the pluggable nature of the GeoServer >> authorization subsystem to keep both modules around. >> >> Best regards >> Andrea >> >> >> On Fri, Mar 10, 2023 at 6:48 PM Gabriel Roldan < >> gabriel.rol...@camptocamp.com> wrote: >> >>> Hi Emmanuele, >>> >>> Thanks for the proposal review and comments. >>> >>> First and foremost, let me stress out the proposal is to _create a >>> branch_, 4.0.x. >>> Since there are several topics that of course need to be discussed and >>> agreed >>> upon, all this work would serve as a concrete platform to do that, with >>> as much >>> proof as possible that everything keeps working. >>> Not to merge or force any of this in the current 3.x series. >>> >>> Follow up inline. >>> >>> On Thu, Mar 9, 2023 at 12:40 PM Emanuele Tajariol < >>> emanuele.tajar...@geosolutionsgroup.com> wrote: >>> >>>> 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] >>>> >>>> Oh that's interesting. Unfortunately I couldn't know, or at least it >>> was easy to oversight, >>> since that issue is three years old, it's not merged, and the title does >>> not relate to the persistence >>> framework; though the description does indeed mention it. Should I've >>> noticed it, it would have >>> saved me a ton of work. >>> >>>> >>>> - 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. >>>> >>>> Yes, the Hibernate criteria API also makes sense. >>> Personally, I prefer QueryDSL for the type-safety part. QueryDSL >>> code-generates classes that >>> let you create arbitrary queries in a type safe way, and adds no runtime >>> dependencies, just a >>> compile-time @Entity annotation processor. >>> In any case this and everything else is up to discussion. >>> >>>> >>>> - *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.* >>>> >>>> As much as I very much agree with the principle, we're kind of in an >>> impossible situation here. >>> I agree having two disparate REST APIs is bad enough. >>> >>> On the other hand, I have been working for a year now on a system that >>> needs to interface with GeoFence. >>> I would rather have the chance to deploy GeoFence standalone or >>> embedded, and be able to use the same >>> REST API regardless, but that's impossible without tons of hacks. >>> >>> It's also difficult to implement a client even if you choose one of >>> them, since there are some inconsistencies like >>> requests to create a Rule accepting a given content type (e.g. >>> application/json) but returning text/plain with the >>> rule id, and then expecting long to fetch the rule. >>> >>> Additionally, in order to replace Spring RMI with an API client, the >>> client would need to implement GeoFence standalone's >>> REST API, but a client working against GeoServer would implement >>> GeoFence embeeded's REST API, so we're just multiplying >>> the maintenance problem. >>> >>> So my proposal is to: >>> 1- use an API-first approach through an OpenAPI specification that's >>> common to both kinds of deployments. >>> 2- *Maintain* the current embedded API for as long as necessary in >>> GeoServer. >>> 3- Also expose the new API as v2, where anyone can use the provided or >>> generate ready to use client libraries in different programming languages >>> >>> (I've actually just finished porting both geoserver plugins, will send a >>> link once I get the configuration part working too in a backward compatible >>> way) >>> >>> Thinking of an upgrade path: >>> For GeoServer embedded, REST API wise, wouldn't make any difference, >>> other than v2 also being available, or not even, could be a configuration >>> choice. >>> For standalone, an upgrade would also mean a standalone GeoFence >>> upgrade, so it doesn't matter if it uses RMI or the new OpenAPI interface >>> to communicate with GeoFence >>> >>> >>>> 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. >>>> >>> nice! >>> >>>> >>>> >>>> That said, I’m quite concerned with the modules refactoring: >>>> >>>> - *They are not strictly needed and motivated by the previous >>>> points.* >>>> >>>> While I disagree (again, for a longer term, on 4.x) , I see my mistake >>> in not emphasizing >>> on the motivation section and only mentioning sharing the maintenance >>> burden in the >>> overview section, I guess I just didn't want to come across as arrogant >>> or patronizing. >>> >>> Since we're kicking off the discussion, allow me to elaborate: >>> >>> I know both Alessio and yourself shall know the codebase from the heart, >>> and that's great, >>> but bear with me, as an outsider and newcomer to the project, I had a >>> rather hard time getting acquainted with it, hence my intention is to >>> make sure the architecture >>> is very clear and upfront, not only for us but for any other potential >>> collaborators. Something >>> closer to a Screaming Architecture >>> <https://blog.cleancoder.com/uncle-bob/2011/09/30/Screaming-Architecture.html>, >>> as my initial struggles were related to figuring out the architecture, >>> and how components relate to each other, not from the persistence >>> viewpoint but from >>> the business domain view. >>> >>> If you look at the following comparison of 3.x and 4.x proposed >>> modularity, I think the 3.x one doesn't >>> say much about what the software system is or does, but instead I see >>> there are apis, persistence, and >>> a gui. >>> The 4.x proposal on the other hand makes it very clear that the business >>> domain has 4 domain units >>> and a common object model, and that's all one would need to look into to >>> understand GeoFence. >>> No Spring, no JPA, no REST, no anything else than pure domain specific >>> logic. >>> Everything else is integration and implementation detail you can dig >>> into if need be. >>> >>> [image: image.png] >>> >>> >>>> - They will likely make it difficult to review and functionally >>>> validate. >>>> >>>> They might. Hence all functional tests are in the domain modules >>> themselves, without requiring digging >>> into integration details, while at the same time serve as base >>> integration tests for both the persistence >>> and client api integrations. >>> The tests (e.g. the most important being RuleReaderServiceImplTest) run >>> against in-memory >>> persistence abstraction implementations that use RuleFilter itself as >>> predicate, through the >>> new RuleFilter.matches(Rule):boolean method, and that helped me a lot >>> to make sure both the openapi >>> client and JPA backed Repositories do the right thing and are hence >>> interchangeable as backing >>> Repositories for the different services. >>> >>> Other things like making the object model immutable also helps to >>> clearly reason about things, like in >>> avoiding side effects with argument objects being changed by functions. >>> >>>> >>>> - They may introduce further issues, along with the potential ones >>>> caused by the already big library upgrade shock. >>>> >>>> Yes they would, as there's no such thing as bug-free software is it? On >>> the bright side we will be taking on the burden of stress >>> testing and fixing for our current customer, and another one in the very >>> near future. >>> >>>> >>>> - 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. >>>> >>>> Indeed. So once again, no rush. I'm only asking for a branch so we have >>> a common place to review, discuss, and >>> coordinate on things. I honestly think having this starting point is >>> much better than trying to make one proposal at a time >>> because it's practically impossible, at least for me, to foresee all >>> these changes, optimizations, or whatever in advance. >>> If we don't take the opportunity to refactor and improve while we have >>> the funding, we might as well end up in endless >>> discussions and consume all those precious resources without anything >>> concrete as outcome. >>> >>> >>>> *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. >>>> >>>> That's not a bad idea at all, thinking of the 3.x series. I can explore >>> it but definitely need >>> to reach a compromise to: >>> - ditch the GWT gui and provide only a spring-boot application for the >>> current (standalone) REST API. Or maybe >>> not even, does anyone use it? or does everyone uses the embedded engine? >>> - keep on using RMI for GeoServer to GeoFence communication >>> >>>> >>>> - 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. >>>> >>>> That would be this one. Given I'm committed to it I'd rather get the >>> go ahead to have a 4.x branch or be forced to work on it from my fork alone. >>> >>> Thanks again for the review and comments, looking forward to yours and >>> anyone else's. >>> >>> Cheers, >>> Gabe. >>> >>> >>>> 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, >> >> Andrea Aime >> >> == >> GeoServer Professional Services from the experts! >> >> Visit http://bit.ly/gs-services-us for more information. >> == >> >> Ing. Andrea Aime >> @geowolf >> Technical Lead >> >> GeoSolutions Group >> phone: +39 0584 962313 >> >> fax: +39 0584 1660272 >> >> mob: +39 339 8844549 >> >> 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 > -- -- Jody Garnett
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
