Re: QueryContext 'id' in CluePackets?


So I've thought about this in the past, and would like to avoid it. 
Though I'm not sure why other than the sick feeling it gives me.

I am thinking a better approach would be to have backends specify the
cluetypes they know how to handle at initialize time.  Then at
processing time, the cpm can pass only cluepackets containing something
a backend is "interested" in.  

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.

I think this has benefits for both speed, debugging, and understanding
the scope of backends.  

What do you guys think?


On Sat, 2003-07-26 at 17:39, DJ Adams wrote:
> 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
> _______________________________________________
> Dashboard-hackers mailing list
> Dashboard-hackers gnome org

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