Re: QueryContext 'id' in CluePackets?

[Alex Graveley <agraveley starbak net>]

Hi,

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?

-Alex

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
> http://www.pipetree.com/qmacro
> 
> 
> _______________________________________________
> Dashboard-hackers mailing list
> Dashboard-hackers gnome org
> http://mail.gnome.org/mailman/listinfo/dashboard-hackers