Damien Saucez wrote: >> If i understand the proposal correctly, the additional load the Oracle >> approach introduces is generated by the sorting of the candidates list. >> Having this in mind, the scheme is actually very similar to the other >> approaches, i.e. the cached lookup in the DB and socket Handling is the >> same. Since sorting is a well known problem and can be done fairly fast >> i don't see this as a huge overhead. But it introduces extra stress on >> the server. > If the sorting time becomes long, you can de activate sorting as the rank > value is in the answer, then, the client has to rank. We should document > this, except if the sorting of the answer is a MUST.
If i understand the draft correct both cases *must* be implemented and supported by the server - however, the section is not 100% clear on that - so maybe we want to state that one of the two *must* be supported instead of both. Currently i am not seeing these queries getting really large, so the sorting should not put a lot of stress on the server. A BitTorrent tracker can just download the map and do it's own ranking, while for a single client it might be too much overhead to download the map entirely to do just a few rankings. Since clients will not query very often this should not be a problem. However, the Oracle approach is dependent on the ordinal query/answer type to be present since it does not want to give out specific weights (in the current state anyway). It just does ranking and *must* sort the answer to remove the original weights. Cheers, Ingmar -- Ingmar Poese [email protected] TU Berlin / Deutsche Telekom Labs Sekr. TEL 4, FG INET www.net.t-labs.tu-berlin.de Ernst-Reuter-Platz 7 10587 Berlin, Germany _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
