QueryContext 'id' in CluePackets?
- From: DJ Adams <dj adams pobox com>
- To: dashboard-hackers gnome org
- Subject: QueryContext 'id' in CluePackets?
- Date: Sat, 26 Jul 2003 22:39:21 +0100
Some backends are simple - they'll find a match on a clue or they won't.
Others may find a match, but might find a better match if the clue packet
comes round again with the original clue paired with a new one within
the same query context.
Finding the balance of weight between the engine and the backend(s) as to
where tuning should lie seems to be currently up in the air. Which is
Backends are currently unaware of the query context, and will for example
make an HTTP call to get a match on each and every incoming clue. While
a cacheing HTTP proxy util would be great in the bigger picture, how about
passing a unique QueryContext id to the backends as an extra element?
This would allow the backends to work out whether they'd seen a clue
already (and possibly already sent a match) in the 'current query round'.
It doesn't blur the boundary between CPM and backends that much, and
could be useful.
Such a unique id could be maintained in the QueryContext class, and
increments when a new instance is instantiated (which is currently done
Just a thought that struck me while harvesting the rest of our early
] [Thread Prev