NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hi Peter, all,Is there some part of the core + extensions framework that simplifies the need for client/server negotiation in some way? The conversation so far seems to imply that if a server supports some set of extensions then any client that wants to access that server had better be able to handle all those extensions.
That seems backwards to me. Isn't it the client that may require certain extensions? If a server doesn't support the extensions the client requires then the client should not continue accessing that server. For example, if a client requires GeoTIFF or CF-netCDF, it can't successfully access a coverage from a server that only supports HDF.
On the other hand, if the server supports the required extensions, it may not matter if it also supports other extensions. Continuing the above example, if the same server supports both CF-netCDF and HDF, the client will be able to access a coverage if that coverage is offered in CF-netCDF. The fact that the server also supports HDF doesn't affect the client.
There is also the scope over which an extensions applies to worry about. For instance, KVP and SOAP support would be server-wide. Whereas the dimensionality of the CRS and encoding format often would be scoped to particular coverages.
Does the core+extension framework provide an overarching way that supported extensions are communicated to clients or does the location of that information depend on the type of extension? For instance, KVP and SOAP I seem to recall are indicated in the GetCapabilities document and so would imply their server-wide scope. The CRS of a coverage and available encoding formats are given for each coverage in the DescribeCoverage document.
Ethan Peter Baumann wrote:
The issue is that each specification (and combination of core/extension specs) applies to both clients and servers simultaneously. That is, some spec combination X which states "a server may offer A or B or C" translates into "a client must be prepared to handle A and B and C".This is the only way that a client really can upfront (ie: before a GetCoverage response is received) decide whether it can talk to this server or not.This is one of our curses: Every "should" in the specification, every "may", every "if...else" multiplies the property space.)more inline... Aaron Braeckel wrote:well, just think about 3-D image pyramids as the analogy to the well-known map navigation accelerator. Also tiling gets a new quality.Renamed thread per Ben's suggestion. If a 2D client talks to a 4D server, it has to be able to detect that the WCS is beyond its capabilities but otherwise I'm not sure that much additional complexity is imposed on clients. A process for describing the dimensionality of the server is definitely important with an N-dimensional WCS, but I think this is already largely covered by the CRS description in the current WCS specification. I see it as another flexible point in the specification. Just as the WCS does not mandate any particular encoding format or specific CRS/data projection, it would not mandate the dimensionality of the data. As in cases where an unknown CRS is in use by a WCS server, a client makes a decision about whether it is capable of handling that WCS implementation.The reason I see N-dimensionality as preferable to a restricteddimensionality is that the restriction: -forces non-2D WCS implementors to fulfill a more complicated extension, even when simple core functionality is all that is needed -increases the number of necessary extensions, at least with how the current extensions are described and laid out. Minimizing the number of extensions seems beneficial to interoperability overall -seems to cut the WCS functionality into groupings at a different angle than the general coverage concept (i.e. less generalized coverage capability) Are there cases I am forgetting that might cause problems for 2D implementors?-Peter
galeon archives: