[Yazlist] Z39.50 operating situations

Sebastian Hammer quinn at indexdata.com
Thu Feb 14 14:18:28 CET 2008


Захаров Андрей wrote:
> hello, i am interesting in such questions:
> 1)As we know Z39.50 server can forward search requests to another Z39.50 
> servers)) and request path can be very long
>  Server1 -> Server2 -> Server3 -> ... ->ServerN
> Is their some kind of timeout or smth, or may be request depth can be 
> tuned up somehow?
>
> 2)and we can imagine situation that request path will be rounded
>  Server1 -> Server2 -> Server3 -> Server1
> Clarify this to me, please. how can we solve such kind of problem?
>
> 3) z39.50 server can make search in different places simultaneously
>                   / server1.db
> server1 -> |  server2
>                   \ server3
>
> imagine situation that first request is completed in 0.1 sec and 5 
> records found, second  2  sec and 20 records found, and third 20 sec 
> (for example) and 3000000 records found.
> 3.1) Does it mean, that request operation time equals 20 sec?
> 3.2) Can server1 return data partially, as its subrequests are complited? 
>   
Actually, it can, but it requires use of a Z39.50 protocol mechanism 
which, to the best of my knowledge, has never been widely implemented, 
if at all. If you look at the protocol specifications at 
www.loc.gov/z3950/agency, you'll find references to 
ResourceControlRequests and Responses which can be used both to 
terminate ongoing processes, and for the server to notify the client 
that partial results are available.

The Z39.50 standard is a remarkable gold mine of untapped 
functionality... in practice, all that most people implement are the 
search/retrieve functionality, but there is a lot more depth to the 
standard that has never been fully explored, and which was largely 
dropped when standardization efforts moved to SRU/SRW. Z39.50 comes from 
an era where people did not think that protocols had to be simple to be 
useful, and it represents a remarkably ambitious attempt to map out the 
entire field of Information Retrieval in a single document. One day, 
someone can probably make a doctoral thesis out of just digging through 
the standard and trying to imagine what those people -- many of whom 
have now moved on to other interests -- imagined when they were writing 
the standards.. so much territory was mapped out just on the basis of 
'wouldn't it be nice', which has never really been explored... and 
today, complex protocols have largely gone out of style in favor of 
simpler technologies.

--Sebastian
> 3.3) How does server1 make multiplexing for such great data volume, as 
> request result need to be sorted?
> 3.4) what if one of the referenced servers is down? how server1 can find 
> it out?
>
> Any useful help will be highly appreciated. Thanks
>
> Andrey
> PS sorry my english
>
>
> _______________________________________________
> Yazlist mailing list
> Yazlist at lists.indexdata.dk
> http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yazlist
>
>   

-- 
Sebastian Hammer, Index Data
quinn at indexdata.com   www.indexdata.com
Ph: (603) 209-6853 Fax: (866) 383-4485





More information about the Yazlist mailing list