It is much much simpler. I think you have a complete different kind
implementation in mind. I will soon create some examples to demonstrate
what I mean.
>>> [log in to unmask] 21-4-04 9:44:37 >>>
Theo van Veen wrote:
>Let me give some examples of possible responses:
Thanks for the clarifying examples.
>Suppose I have the following query:
>Then server A may respond with:
>server B may respond with
This is more or less a scan, as far as I can see. The SRW scan is
bounded to an index, but then again, all valid indexes are known
the explain functionality.
So why should a client not just use a regular scan when it does not
sufficient hits? This way, the decision is on the side of the client,
which is the part of the system which is (hopefully) brain-powered in
the end, and can make good decisions.
>server C may respond with
><hitsPerIndex> (for query=theo)
This is exactly what I refer to when using the term "indexes spread
If a client wants to do anything inteligent with this information, it
has to cache it - not only just a few seconds, but over many, many
sessions. Essentially, a client has to build an inverted index
(hashtable) over all the atomic parts of a query ( in this example
"theo"), and has to record which server had it, and how many times in
which index field. Otherwise, it has no chance to adaptive guide the
user to better queries.
For example, your response would add the following data to the hash
theo[server C][any] = 99900
theo[server C][dc.subject] = 5
theo[server C][dc.creator] = 50
theo[server C][composer] = 10
This definitely _is_ an inverted index: it tells where to be lucky
queries for the
word "theo", and how lucky queries must be formulated.
It is distributed in the sense that a given client only has partial
knowledge over all
inverted indexed - namely only those, it had asked for.
But it lacks a fundamental property for being really usefull: other
clients, with their partial knowledge of other arts of the distributed
hash table, do not know how to use their neighboring clients parts of
the whole hash table, so they can not take advantage of other clients
This is because clients do not know clients, just servers. And even if
they did, SRW do not define a client-client protocol, so the can't
to eachother to exchange information.
Enters the need of a grid or peer-to-peer protocol.
So the only thing resulting in this - keeping the SRW client-server
philosophy - is that a client has to build indexes over the servers it
knows, and can't exchange it with others. But really - who's best at
creating indexing structures?? The server.
So my question is: why should a client remember hash tables, when a
sever is much better at it? And when we do not want to leave the
client-server philosophy with SRW ?
How does the client update it's hash tables when records are
on the server?
IMHO this is not really gonna work before updating issues are dealt
with, and the benefit for the client might not be as large as
Marc Cromme, Index Data