From: Mike Taylor Date: Wed, 3 May 2006 14:56:07 +0000 (+0000) Subject: Improvements to MULTI description. X-Git-Tag: METAPROXY.1.0.3~9 X-Git-Url: http://lists.indexdata.dk/?a=commitdiff_plain;h=f96e54d54ae8d60f27f2711fbbbc39b1a29eeb97;p=metaproxy-moved-to-github.git Improvements to MULTI description. --- diff --git a/doc/book.xml b/doc/book.xml index 3faf161..b3ab960 100644 --- a/doc/book.xml +++ b/doc/book.xml @@ -1,4 +1,4 @@ - + Metaproxy - User's Guide and Reference @@ -1221,15 +1221,18 @@ Z> >the HTTP 1.1 specification. - The role of the virt_db filter is to rewrite - this otherInfo packet dependent on the virtual database that the - client wants to search. + Within Metaproxy, Search requests that are part of the same + session as an Init request that carries a + VAL_PROXY otherInfo are also annotated with the + same information. The role of the virt_db + filter is to rewrite this otherInfo packet dependent on the + virtual database that the client wants to search. When Metaproxy receives a Z39.50 Init request from a client, it doesn't immediately forward that request to the back-end server. Why not? Because it doesn't know which - back-end server to forward it to until the client sends a search + back-end server to forward it to until the client sends a Search request that specifies the database that it wants to search in. Instead, it just treasures the Init request up in its heart; and, later, the first time the client does a search on one of the @@ -1259,12 +1262,10 @@ Z> <target> elements. What does this mean? Only that the filter will add multiple VAL_PROXY otherInfo packets to the - search requests that pass through it. That's because the virtual + Search requests that pass through it. That's because the virtual DB filter is dumb, and does exactly what it's told - no more, no less. - - - If a search request with multiple VAL_PROXY + If a Search request with multiple VAL_PROXY otherInfo packets reaches a z3950_client filter, this is an error. That filter doesn't know how to deal with multiple targets, so it will either just pick one and search @@ -1274,16 +1275,16 @@ Z> The multi filter comes to the rescue! This is the only filter that knows how to deal with multiple VAL_PROXY otherInfo packets, and it does so by - making multiple copies of the entire search-request: one for each + making multiple copies of the entire Search request: one for each VAL_PROXY. Each of these new copies is then - passed down through the remaining filters in the route, instead of - the original one. (The copies are handled in parallel though the - spawning of new threads.) Since the copies each have ony one + passed down through the remaining filters in the route. (The + copies are handled in parallel though the + spawning of new threads.) Since the copies each have only one VAL_PROXY otherInfo, they can be handled by the z3950_client filter, which happily deals with each one individually. When the results of the individual searches come back up to the multi filter, it - merges them into a single search-response, which is what + merges them into a single Search response, which is what eventually makes it back to the client.