Re: New addressbook backend.



On Fri, 2004-02-06 at 02:48, Jim McDonald wrote: 
> [...]
> 
> > Yeah, I'm saying there may be backends which want to return matches
> > which have different categories.
> 
> I wondered about this, but figured that it was pretty unlikely that a
> single backend would have multiple categories of match.  Not a problem to
> change internally, though.

Yeah, I think it probably is, but I don't want to make it
architecturally infeasible.  Also, I think this helps later if we want
to group by something other than category.

> > Getting the frontend to structure the cluepacket is part of the
> > problem.  Maintaining that structure information as you pass the
> > cluepacket around, chain the clues, and find matches is another part.
> > They are both important.
> 
> Do you still want the frontend and cluepacket information available to
> each match when it's in the engine, or just when it's being gathered from
> the backend?  The former is currently in the code, the latter is not a
> problem to implement but in this case we're starting to hold an awful lot
> of information for each match, especially if there has been extensive
> cluechaining going on.  I'm not sure that a match, once it has been
> processed and inserted in to the display list, needs that much context,
> but if you think it does then fair enough.

I was thinking this could get maintained with references to the objects;
so we keep the entire clue/match graph in memory, but we don't duplicate
all this information for each match.

For a given match, you want to be able to answer questions like:

        1) What clue or set of clues triggered this match?
        
        2) What cluepacket do they come from, originally?
        
        3) What frontend sent them?
        
        ...
        
Besides being nice for drawing graphs, this information might come in
handy.

>    I have implemented the fixes that we've been talking about here, so
>    I'll dump them into CVS once 0.1 has been finalised.  In the meantime
>    I'll put together another patch this weekend so that people can see
>    what's going on.

Okay, awesome.

Nat





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