Re: QueryContext 'id' in CluePackets?

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

> 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
> _______________________________________________
> Dashboard-hackers mailing list
> Dashboard-hackers gnome org

It is unbecoming for young men to utter maxims.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]