[Yazlist] Z39.50 operating situations
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
> 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
> PS sorry my english
> Yazlist mailing list
> Yazlist at lists.indexdata.dk
Sebastian Hammer, Index Data
quinn at indexdata.com www.indexdata.com
Ph: (603) 209-6853 Fax: (866) 383-4485
More information about the Yazlist