Re: QueryContext 'id' in CluePackets?

["Imran S. Patel" <imran cs ucsb edu>]

> a simple backend that does e.g. an HTTP fetch on a single clue (type), 
> receives the same clue in the course of a number of backends 'sweeps'
> sourced from one querycontext. In the course of that sweep, more clues
> are added (from backends) to the original clue. The dilemma here is 
> that the engine can't be sure whether the backend is only matching on
> single clues or clue combinations. So it must send the clue (and any
Well, extending your example, the backend might have done an HTTP fetch on
seeing a clue C and it might have done something else on seeing clue C AND
D. So it might make sense in that case to resend the clues to the backend.
More generally, I don't think that the CPM can be made to understand how a
particular backend works.

imran
> partnered clues) a second time, which a simple backend would then 
> blindly make another HTTP call for. Hence the (original) idea of the
> qc 'id', later the "seen by backend" data, and recently the use of 
> MatchCache.
> 
> dj
> http://www.pipetree.com/qmacro
> _______________________________________________
> Dashboard-hackers mailing list
> Dashboard-hackers gnome org
> http://mail.gnome.org/mailman/listinfo/dashboard-hackers
> 

-- 
-----------------------------------------------------------------------------
It is unbecoming for young men to utter maxims.
    				-Aristotle