Ian writes:
> The idea is that you have a search query like "contains("hello") and
> contains("goodbye") or matches("fred")". On recieving a request for
> data matching this key, each plain-text key in the datastore is compared
> against the search and given a score between 0 and 1, 1 being a perfect
> match (fuzzy logic is used to determine this score). If any data gets a
> 1 then it is returned immediately. If not, the best score on the node
> is checked against one or more "best so far" scores transmitted with the
> search. If one of our local keys beats these scores then it is added to
> this list in the appropriate place. The request is then forwarded in
> the usual manner to the node corresponding to the highest scoring key.
> When the request times out or finds a perfect match it passes back along
> the path, bringing with it the list of "best-so-far" keys.
I don't think this will work. That is, it won't find the best results,
and it may not find any results, even if there are plenty of matches in
the net.
Freenet retrieval works today because inserts and requests tend to take
the same path and head towards the same places. That is because the key
is the same in both cases. On insert of a message with Key1, if that is
closer to Key2 than to Key3, it heads towards the node holding Key2. On
retrieval, the same thing happens: a request for Key1 heads towards the
node with Key2 if it is closer to that than Key3.
But with Ian's fuzzy search idea, this won't happen. If we insert data
with keywords A, B, C, D, and E, and we do a request for "(B and D) or Z",
these won't head in the same direction.
On insert, we would be "close" to such keys as A,C,E,F; or C,D,E,G.
We would route towards those nodes. But on search, we would not give a
high score for those nodes, and we would route away from them.
This search proposal breaks the fundamental principle that makes Freenet
work, which is that inserts and requests are routed in the same way.
It will no longer be true that the closeness metric will give the same
results on search as it does on insert. Without that constraint, I
don't see how you can expect to find your desired data in the vastness
of the net.
I am sorry to be a naysayer, but I think the burden should be on
the proposal to show a reason why it would work, in order to justify
implementing it.
Hal
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
