Re: Cluechaining and Original Clues



> On Sat, 2003-12-20 at 11:41, Jim McDonald wrote:

Welcome back!  Hope you had a good break.

[...]

> There were a few premises driving the current (when you wrote this)
> design:
>
>        * Cluechaining is a way for backends to augment an incoming
>        cluepacket with additional clues that might help other backends
>        produce more and better matches.
>
>        * New, chained clues can result in an augmented query which is
>        not just broader, but also potentially more specific.
>
>        * Backends should be stateless across a query, so that they are
>        easy to write.

It's the third option that bites.  If you want to make your backends
stateless then you shouldn't feed them stuff that you just fed them a few
seconds ago, because they won't know not to bother with it.  You need to
be doing a bit of state elsewhere to keep the overheads down.
> So the notion was that the rewritten cluepackets -- the ones with the
> new, chained clues in them -- would indeed be redundant and contain
> clues which overlap with old clues.

If a cluechainer has generated lots more clues then for the simple (i.e.
one-clue-at-a-time) backends we'd only want them to work with the new
clues, as they've already returned results for the previous clues and so
won't be producing anything new.  For the complex backends, of which there
are currently 1, they could call the method I proposed to get all of the
clues from the cluepacket and its parents, and do whatever you wish with
the complete set of clues.
   This seems to be a suitable balance in terms of keeping the simple
   backends simple, whilst allowing for the complex backends to look at
   the entire set of clues from both the frontend and the cluechainers.
> Nat

Cheers,
Jim.
-- 
Jim McDonald - Jim mcdee net





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