> b) the temptation is to start doing client/server snooping - i.e.
> have special case code for doing X if the client is from a
> particular vendor of a particular version, else doing Y if from
> this vendor, else do Z.

This is something which is already happening with servers and metasearch
engines. The NISO metasearch Initiative will, hopefully, soon publish
guidelines on how a MSE can identify itself to a search engine. Even without
official publication 3 of the MSE vendors are identifying themselves (via
the "agent=" attribute in http, where this matters), and the SEs are at the
very least keeping statistics.

The typical web site is a good example
> (where it might do things one way for IE, but another for
> Netscape, and breaks totally in Opera etc.). That defeats the
> whole point of interoperability, and we already have mechanisms
> for private extension (where any client can indicate to a server
> that it wants something clever not normally in the spec, rather
> than the server just doing the clever thing for a particular
> client vendor/version).

Given that we are in the position where there are multiple instances of the
same client and server software across different organisations, it does make
sense for the server to set up a specific method of communicating with a
specific client - if there are enough of them, and there is some gain to one
or both sides. This may be in reduced overhead for particular clients
because they don't need everything (a full html user screen for returned
results for example is a serious waste of resources for a MSE/SE
communication, when an XML structure will be of more use to both sides), or
the service can be improved (extended record structures including more
fields, or even the presence of a particular set of ExtraData, applicable to
any protocol).

In a metasearch environment the information for the SRU/W servers will be
collected alongside that for http, Z39.50, SQL, telnet, etc. servers and the
more information about the software and version used the better for keeping
things working. It is the case that much of this information is obtained
'out of band' (via telephone/email) so storing it is useful in the event
that a particular implementation sends back less then complete information -
there is a 'fall back' position available. (I know that, for example, not
sending a schema URI with the record is non compliant for SRU/W, but there
will be some programmer out there eventually who decides it is a waste of
time. As a community the size of stick we can wave at them is limited. If
they have valuable data users will want to access it however 'compliant'
they actually are.) So the more information the better.

-------

Final point; when we (Muse this time) store information about a server, we
differentiate the software information (name, version) from the
configuration (addresses, ports) and the access (method, parameters)
information. Each of these is an independently variable set of data, so we
model it that way. I appreciate the hacking comments, but my plea is for as
much information as possible to be allowed for, so that we get just some of
it.

Peter