Yep, spot on.
On Wed, 10 Feb 2021 at 05:47, Andrea Aime <andrea.a...@geo-solutions.it> wrote: > On Wed, Feb 10, 2021 at 1:58 AM Gabriel Roldan <gabriel.rol...@gmail.com> > wrote: > >> First and foremost, I am generating a Java client from the OpenAPI >> documents. Not the swagger 2 ones provided as documentation, but OAS3 ones >> created using those as reference. >> >> Here's a project I just made public a couple of days ago: >> https://github.com/camptocamp/geoserver-rest-openapi >> >> At camptocamp we're using it in production for over a year in an internal >> project, but now I moved it as a standalone project to be used by the OSS >> project geOrchestra. >> >> It only implements the minimum I needed for that internal project so far. >> That is, working with workspaces, datastores, feature types, layers, and >> styles. And probably not even all of it. >> >> Also, it focuses on JSON representation only. >> > > Nice to see a Java based client, geoserver-manager died several years ago > leaving no replacement as a Java based GeoServer REST client. > If enough people are interested, and it lives long enough, no doubt it > will eventually cover fully functionality, or close to. > > >> That said, writing the OAS3 files and the generated client wrapper code >> is hard, often having to debug GeoServer itself to figure out what's going >> on in the server to be able of mimicking it on the api definition. There >> are several inconsistencies, not only in the outdated/incomplete swagger2 >> files, but in the server itself, most of which I think are due to using >> XStream to generate the JSON representations, like a single object instead >> of an array when an array is expected but the result contains a single >> element, excessive wrapping of objects, and several other annoyances I >> didn't care to document properly at the time, but believe me, I thought >> having a working set of OAS3 specs would be a nice first step towards >> defining a v2 api with clearly defined api contracts and code-generated >> server stubs. >> > > Yes, we are painfully aware of all the above. > > >> Achieving that would of course require significant resources so it most >> probably will die in the wish-list. >> > > Indeed, a fresh start for REST services would require solid funding and a > new dedicated maintainer for it. > The existing REST API needs close to no maintenance, besides the bug > fixing and new functionality, which are both directly funded, when > happening, > Also the existing clients are working good enough for many, so the two > REST APIs would need to be kept alive for a few years, > giving existing deployers time to migrate. > > That's the main crux of all this discussion, there is a big chasm between > those that like different, newer, cleaner functionality, > but have nothing to offer in terms of funds or development time, and those > that are trying to keep the project alive, already > fully busy with paid work against the project, and already having a > working solution for the issue at hand. > > I see kind of the same issue happening down in OGC API modules, they are > moving one testbed or code sprint at a time, but there > is very little business around them (mostly research projects), cause they > are providing a different solution to a problem that > was solved already 20 years ago, and for which many have working clients. > Those that don't are clamoring for the new API, > sure, but also providing no resources to make the modules go up and > graduate. > > I'm just glad despite all the noise, we are managing to keep the project > alive and going, pruning dead branches and moving on, > instead of living the current situation in GDAL, where the project > maintainer seems to have had enough of all the external requests and > pressure, > and disappeared from both the mailing list and twitter (I surely hope it's > just a vacation.... we'll see). > > Cheers > Andrea > > == GeoServer Professional Services from the experts! Visit > http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf > Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa > (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 > http://www.geo-solutions.it 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.* > -- Gabriel Roldán
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
