On Tue, 8 Sep 2020 at 23:39, Jody Garnett <[email protected]> wrote:
> A lot to dig into there, in general I would love to see these interfaces > simplify and become less complex over time. One aspect I like in your > "rant" that I like is the consistent series of XXXRepository instances. > Yes, it's more or less what you would expect nowadays. Stratus does that, but on its own, had to deal with all the extra-stuff besides the repository abstractions themselves. And it's not going to get any easier if we don't make it so. > > As long as you are in the mix: > - The naming of CatalogFacade always trips me up. > It strikes me as odd too, though I can live with it provided it's an enabling abstraction and not a stone in the shoes. > - I would love to factor ResourcePool caches into strong types (rather > than many Map<String,Object> caches) > Digging deeper there are other things that would make sense, that's a good one, especially because it's public api. Unrelated to the problem I'm trying to solve though, but very much worth considering. -- > Jody Garnett > > > On Sat, 5 Sep 2020 at 20:39, Gabriel Roldan <[email protected]> > wrote: > >> Hello again, >> >> by working on the project mentioned in the previous message >> <https://github.com/camptocamp/geoserver-microservices>, I've come >> across the need to implement an alternative catalog and configuration >> backend. Although for the time being it's using the jdbcconfig/jdbcstore >> community modules, it is a design goal of the project to make it easier to >> implement such plug-ins. >> >> As such, after an in-depth review of the current catalog/config ease of >> extensibility, adding to my previous experience with it, I've come up with >> the following considerations I'd like us to discuss. >> >> Please read the following as it's markup: >> >> https://github.com/camptocamp/geoserver-microservices/blob/11ed77dc/catalog-support/pluggable-catalog-support/README.md >> >> Based on those notes, my intention is to either: >> - implement those improvements/fixed as a community module >> - work directly over the default CatalogImpl/CatalogFacade et all >> >> For that, I'm looking for guidance/opinions on how to proceed. Either way >> is fine with me, I could set up an improvement proposal, or contribute >> what's related to the catalog/catalog facade as totally separate >> implementations of CatalogImpl and CatalogFacadeImpl(*) as a community >> module, so that whomever is interested can use those as their >> implementations. >> >> (*) same goes for GeoServerImpl/DefaultGeoServerFacade, it's just that >> it's not as involved as the catalog counterpart, or rather I haven't got >> into it in that much depth. >> >> Cheers, >> -- >> Gabriel Roldán >> _______________________________________________ >> Geoserver-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >> > -- Gabriel Roldán
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
