QueryContext 'id' in CluePackets?

[DJ Adams <dj adams pobox com>]

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 
fine. 

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
in CluePacketManager.ProcessFrontendCluePacket().

Just a thought that struck me while harvesting the rest of our early
potatoes ...

dj
http://www.pipetree.com/qmacro