[ZOOM] Some 1.4 options questions

[Adam Dickmeiss]

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
>>>name?
>>>      
>>>
>>"server"?
>>    
>>
>
>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 
local socket
    $s = connect("tcp:myzserver", "z39.50");
    $s = connect("ssl:myserver", "z39.50");

Perhaps, even
    $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 
still work.

>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
>  
>
[snip]

>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!

-- Adam

>Alan
>
>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.
>  
>