Rob Atkinson wrote: > There is nothing intrinsically postgis about the solution, we envisage > it a JDBC capability. I agree :-) > A parameter with a sensible default could advertise the table or > function that would be interrogated to find functions intended to be > advertised. > > My could attempt to call a function getRegisteredFunctions(key) where > key is a configuration parameter that may be null. Such a function > could just hardcode function names if you only want a couple. > > The alternative would be to allow the JDBC connection to access a > table, so different user logins could access different sets of > functions. This may be more work at the db administration end. > > Open to ideas as to which is best strategy. I would go with a single table for now; not sure what to call it. My initial feedback was more about how to advertise what functions are available - so geoserver can report them as available etc.
There is one thing to check in the WFS specification; I am under the impression that server needs to report back a filter capabilities (including a function list). These capabilities may be for all feature types? Or hopefully on a feature type by feature type basis ... depending on what the specification says we may need to set up a change request for the OGC. Jody ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
