I think this needs a geotools proposal to gather the results of this thread into a form for folks to review.
While I could review this thread in order to chime in, it would really benefit from a proposal describing proposed API / functionality change. This is a geotools level change right? -- Jody Garnett On Dec 4, 2023 at 10:06:08 PM, Carsten Klein <c.kl...@datagis.com> wrote: > Hi Andrea, > > what's next with the SQL-encodable filter functions. You said > > I'll let the other core developers chime in and help with a decision. > > > Is there anything new? Do you expect me to issue a Jira CR? Or even a > ready to use patch? > > I'd much appreciate if someone of the core devs could make these > (simple) changes, since I have not yet any experiences to hack GeoTools > (and test with GeoServer). Setting up all this is perhaps much more > effort than the patch itself (which a coder used to work with both > projects will likely have finished in some minutes). > > Cheers > Carsten > > Am 25.10.2023 um 00:52 schrieb Andrea Aime: > > Yes, I remember NativeFilter, there was some discussion about whether > > to allow > > that interface to exist at all, the final agreement was that, yes, ok, > > we can have it, > > as long as it's a low level programmer oriented tool, which cannot be > > seen by end users. > > > And we also have a similar interface for functions called > > InternalFunction, which has a similar > > attitude, a function that is not meant to be seen outside of code > > (cannot be parsed from CQL or Filter XML encoding for example)... > > although this one has > > no usage in SQL encoding. > > > Perhaps a NativeFunction base interface could be used, to indicate > > that the function > > is not meant to be included in capabilities documents (odd usage, not > > working cross store), > > and per store sub-interfaces like PostgisNativeFunction could be used > > to indicate the > > function can be written as is in PostGIS for example. > > > I still don't like it much in general, as its usage would be limited > > to vendor extensions, but > > I'm not going to cast a -1 either, as I see the convenience of the > > approach for custom > > GeoServer extensions. > > I'll let the other core developers chime in and help with a decision. > > > Cheers > > Andrea > >
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
