Hey Jody, On Fri, Mar 10, 2023 at 4:04 PM Jody Garnett <jody.garn...@gmail.com> wrote:
> Gabe: > > My initial feedback is - wow that is a big risk doing a month of work > without having GSIP on the table for discussion on technical direction. > I think I understand the risk. Bear with me that's the reason why I asked to create a GSIP, being the first one related to GeoFence other than the one to promote the GeoServer plugins from community to extension (GSIP-164), where 3 of 4 positive votes are from Geosolutions PSC members. It is hard enough to jump into a project. I had my fears about the overall solution and hence needed more than a quick POC to be sure everything would work. The ones who know the codebase will understand this: If RuleReaderServiceImpl doesn't work, then the work isn't any good, since that one kind of gathers everything together (authorization, rule and adminrule management, and resolving user roles). So the more I tried to keep it focused, the deeper the rabbit hole. This is by no means a complaint, it's just a fact that 100% of commits to GeoFence that have any functionality come from Geosolutions folks that never needed to make a GSIP for a change. Point of the proposal process is to reduce risk for camptocamp and > community interaction to avoid being left with either a lot of re-work or a > fork as indicated by your 4.x version number :) > > In the future try to align GSIP process with some kind of design milestone > for your customer; so you can get confirmation from your customer and the > community before sinking a ton of budget into activity. > Camptocamp delegates on me to set the technical direction on this particular endeavor. None of the two customers involved care if we use GeoFence, one for sure doesn't even care if it's Open Source, as long as it solves the problem. So I'm going through great lengths for it to be. > It could be you found it easer to do a proof-of-concept and then share > the design for discussion; but I wish to ensure you have budget for > collaboration and compromise in reserve. Basic project management stuff for > both geoserver and Camptocamp I admit; but it is important to control risk > using the communication tools we have. > At the same time, given I'll be in charge of project maintenance for these customers for the foreseeable future, I'd rather work on a codebase that's closer to pleasure to work on than to a hassle. Again, no offense, but it is what it is. And so I'm just asking for the minimum possible which is a branch, and offering my commitment to work on every and any concern, be it related to design, architecture, or anything, at any pace, because now I can, before I couldn't. It would have been a ton of unknowns. > > For the actual proposal I am presently -0; since I do not feel > knowledgeable on geofence and do not have active customers using the > technology. It would be much easier for collaboration if each one of the > risks you mentioned were his own GSIP; as the all-or-nothing thing makes > discussion difficult to follow. > > If I understand: > > 1) Google's Generic DAO Framework --> what is the proposed solution for > this? > >From a design point of view, we have Services that need to fetch rules from the persistence layer using filter predicates. GeoFence has a RuleFilter class, but the services used Google's Generic DAO to to build DAO's layer predicates. The proposal is to use RuleFilter itself as the predicate language for the persistence abstractions, and let the implementations translate RuleFilter to native predicates as they wish. e.g.: RuleAdminService -> RuleRepository.findAll(org.geoserver.geofence.filter.RuleFilter) instead of: RuleAdminService -> RuleDAO.search(com.googlecode.genericdao.search.ISearch) > Looks like it may be some automatic code generation? Hard to see > >From the implementation point of view, there are two RuleRepository implementations. One works against the database using JPA, and maps RuleFilter to a com.querydsl.core.types.Predicate, which is converted to an SQL/JPA query at runtime. For this one we could also translate RuleFilter to Hibernate's Criteria API instead, which is lacking in terms of type safety, but can be done. The other RuleRepository implementation is backed by a REST API client. The client itself is code-generated from the OpenAPI spec. The RuleRepository implementation maps payloads from the API object model to the business object model, and HTTP error codes to expected Exception types . Hence you can run RuleAdminService and RuleReaderService in the geoserver plugins hitting either the db, or a remote GeoFence instance. > 2) Hibernate Spatial 1.1.3.2 replacement --> upgrade > > What is the impact of upgrading to a newer version? Migration challenges > for existing users to address? > > reading: I see you identified h2 upgrade as a problem. I think this is a > key upgrade that is blocking work :( > The challenge is the H2 database upgrade. I think that'd be why Emmanuele's branch is three years old. > 3) REST API differences between standalone and embedded --> definition of > a new OpenAPI 3.0 interface > > What is impacted by this? Is it just the integration between geoserver and > geofence or is there more functionality (such as GeoNode or MapStore) that > requires care? > My understanding from the PMC meeting the other day, I might be wrong, is anyone is hardly using the standalone version of the REST API, so much that Andrea mentioned they thought of ditching it and just keep the one provided by GeoServer. > reading: I see you acknowledge the REST API change. Is it possible to run > both a v1 and a v2 rest api concurrently? We will need to hear from the > community what the impact of this change is. It is always hard when your > work impacts others as you need to ensure they have budget to proceed with > the change. > Yes, that's the proposal, to let the GeoServer plugin run both v1 and v2. In any case, it'd use v2 to communicate with a remote GeoFence when using the remote plugin (to replace Spring RMI), but whether to expose the v2 can be a configuration choice. Meanwhile, anyone can use the OpenAPI specification to code-generate clients and upgrade to v2 at their own pace. > > 4) Use of spring RMI --> > > Repository adapters? Not sure I follow the approach. > As explained above. The idea is to get rid of Spring RMI as it's deprecated, and use the REST API to fetch data from Geofence, while eating our own dogfood. Cheers, Gabe > > -- > Jody Garnett > > > On Tue, Mar 7, 2023 at 6:34 PM 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 >> >
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
