[ZOOM] Some 1.4 options questions
adam at indexdata.dk
Thu Feb 5 10:32:58 CET 2004
Alan Kent wrote:
>On Wed, Feb 04, 2004 at 10:41:27AM +0000, Mike Taylor wrote:
>>>So host is, admitted, is a terrible name. What would be better a
>If things go this way (that is, have a single server string allowing
>it to be somewhat opaque to the API), it would be good to standardise
>the strings forms. Eg: precisely how to specify a
>(1) Z39.50 connection "z3950:" host [ ":" port ] ?
>(2) SRW connection "srw:" host [ ":" port ] "/" database ?
>(3) SRU connection "sru:" host [ ":" port ] "/" database ?
While term "z3950:" may be the standard way to say Z39.50 over BER over
TCP/IP, I don't like in ZOOM (or in our code) that we have transport and
protocol squashed together. Let me explain.
In the good'ld days in YAZ we had transports tcp: (RFC1729: ber over
TCP/IP) and osi: . And we had protocols SR and Z39.50 which were similar
but _not_ the same. While we don't support osi: anymore we now have
unix: (unix domain, stream on localhost) sockets as well. Unix domain
sockets are excellent if you have a local server and don't want to
reserve a port and they're fast too - highly recommened.
The SRW/SRU protocols makes it more apparent that we need a better
model. While SRU is bound to HTTP protocols HTTP and HTTPS!, SRW/SOAP
based protocols works on tons of transports depending on the tools used.
As a result we should have two components to specify a server /
service?. The transport+location and protocol.
$s = connect("http://myservice", "srw");
$s = connect("jabber:jabberservice", "srw");
$s = connect("http://myservice", "sru");
$s = connect("https://mysecureservice", "sru");
$s = connect("unix:/var/tmp/mylocalsocket", "sru"); // SRU over
$s = connect("tcp:myzserver", "z39.50");
$s = connect("ssl:myserver", "z39.50");
$s = connect("http://mygoogleservice", "google"); // Google SOAP
$s = connect("http://explainurl", "explain"); // Get Explain record
via HTTP and auto-configure.
We need to think about how this relates to Explain!
It may be that the protocol should be specified in a slightly different
way in the form of a URI or somehing.
>The above are just examples. Adam posted what he accepted recently,
>but I dont think it was precise in terms of the grammar of where to
>put slashes and colons etc. May as well use the grammar already
>supported by someone (eg: YAZ).
My ambition is that we define as little as possible. So http: _is_ a
URL. It's only for tcp: / ssl: / unix: we need to specify it. I admit
that tcp: / ssl: are bad terms, but they are not sufficiently bad IMHO
to be renamed.
The real benifit of having the transport separate is that you can throw
the transport+uri to the lower level tools without even now "how" the
transport works, e.g. SOAP/web tool.
>>>In the easy mode, start, count and presentChunk is first record to
>>>fetch, number of records to fetch and number of records to fetch in
>>>each present request respectively. The special presentChunk value 0,
>>>means present all records in one go (count records).
>>What effect does "count" have, then?
The recordChunk is merely a hint. Don't put it in the spec! I'll explain
what it does one more time anyway. All Z39.50 tools I know don't have a
SAX like interface meaning that you don't get to see partial results in
a PDU before the whole PDU has been received. Decoding takes place when
a full PDU has been received - is another way to say the same.
Now the lazy ZOOM web programmer wants to show 20 records. So count=20.
The programmer wants to show 3 records at a time, so recordChunk is 3.
Suppose that there are at least 20 hits, then the first 3 records are
part of a piggyback search response (1-3). A number of present
requests/responses are transmitted with 3 records in response, except
for the last response which will hold 2 records.. With PHP/YAZ the
programmer gets to know when each present response have been received
and therefore the records may be shown ... Don't put recordChunk in the
ZOOM spec. It's a hack and a hint. If a server doesn't know it things
>My reading is 'start' & 'count' are for piggyback search requests, and
>'presentChunk' is for present requests. If this was the case, would you
>still have the 'piggyback' option? If 'count' is zero, then there is
>no piggyback in effect.
This is how it works in ZOOM in YAZ. If count is non-zero and piggyback
is 0, the server will send a separate present request. The server will
also send a present request if either sorting or string schema is in
effect (implied piggback disabled).
>>>It is a little confusing, though. The notion of "default" settings
>>>or settings getting propagated to child instances ...
>>Sorry, I would have been open to do this differently when we were just
>>starting out with ZOOM, but I don't want to change everything now...
>I agree. Appologies for bringing the topic up again.
>By the way, I am pottering along again on my ZOOM implementation.
>I am starting from the abstract spec however, not the current Java
>If anyone is interested, I can put up beta Javadoc of the API in the
>near future for comment - knowing that it is not strictly ZOOM.
Hope you enjoy implementing it!
>ps: I am hoping to release a low level packet Z39.50 encode/decode stuff
>for Java soon too. My ZOOM-ish layer is built on top of this library.
More information about the ZOOM