Re: QueryContext 'id' in CluePackets?

[DJ Adams <dj adams pobox com>]

Sorry, I omitted to respond to this important bit.

> Also, the cpm can watch as clues are chained, and only resend the
> modified cluepacket to a backend if the changed clues are ones it has
> interest in.  Or if a cluetype suddenly become present that previously
> wasn't available and excluded passage to a backend.

What this doesn't solve, and it's the original problem that got me started
thinking about this, is the following:

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