I'll probably get it wrong at some point, but i'll try to give the SQI
point of view

> Or they could have adopted CQL from SRW, even if they had decided on
> using different wrappers for the communications.

As far as I can tell, you can use CQL with SQI- SQI has no defined
query language, it only deals with the messaging. At the moment, you
have to agree the particular query syntax you'll use beforehand. They
didn't want to commit to anything with an existing datamodel or syntax,
which is why they seemed to have been wary of any of the Z39.50
derivatives. That said- they are involving  some ZING representatives
in the development of SQI, apparently.

> That said, SRW could fairly easily be bound to SOAP over SMTP which
> would allow asynchronous communications. We haven't included such a
> binding in the spec.s because no-one has been asking for one - whilst
> supported, asynchronous operations are not that common in Z39.50
> implementations.

I think the main motivations for the aynchronous feature are a) a
complex brokerage system that regulates all traffic with some very
basic/idiosynchratic 'repositories' (VLEs basically) in hundreds of
schools (Celebrate) and b) lots of Edutella peer to peer clients that
farm out queries across all their nodes.  There's some legacy, in other
words.

SQI is so basic that you probably could do it bound to SOAP over SMTP-
the essence of the aynchronous mode is that the target tells the source
to set up a listener; message form and transport protocol is whatever
you like. As Scott said, pretty much like OKI- for better or worse.

> A more appropriate mechanism might be to make use of standards such as
> WS-Notification, WS-Events, etc.  This is part of the reason we haven't
> considered asynchronous communication (apart from lack of people
> shouting for each) - the WebService standards in this space haven't
> really solidified.

I'm not sufficiently familiar with the WS specs to know what kind of
overhead is involved in implementation- if it requires any serious XML
Schema parsing, it probably knocks out a substantial part of their
audience.

> To be honest, I'm not convinced that a client using multiple threads
> but
> a synchronous communications model wouldn't fit the requirements (and
> handling asynchronous communications properly requires multiple threads
> anyway).

I'm guessing wildly that the threading issue is also stumped by the
peer-to-peer clients: they must handle shedloads of queries in a simple
app. They probably only spawn threads per connection, not per query,
and just match any response IDs to their own source IDs: not mine -
send on, mine - parse message.

Having said all that, the peer-to-peer issue could as well be resolved
by a gateway to a 'proper' protocol- which is how Splash and LionShare
do it, as far as I know.

Wilbert

>> As for service discovery, isn't that what UDDI is for? :-)
>
> We already have two competing standards for this already - UDDI and
> ebXML Registries. We certainly do not need a third!
>
> Matthew Dovey
> Oxford University