by working on the project mentioned in the previous message, 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.
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.
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.
As long as you are in the mix:
The naming of CatalogFacade always trips me up.
I would love to factor ResourcePool caches into strong types (rather than many Map<String,Object> caches)
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.