Re: New addressbook backend.

[Nat Friedman <nat novell com>]

On Tue, 2004-02-03 at 00:59, Jim McDonald wrote:
> >        * Matches should have types, so that you can map a type to a
> >        renderer:
> >
> >        	Match m = new Match ("BugzillaBug");
> 
> [...]
> 
> I put this information in the result sets as a category, as each result
> from a backend had the same category.  The new patch groups results by
> category as well, so that should be easy enough to manage in terms of
> rendering.  The rest of the stuff you mention on rendering fits pretty
> much with how I envisaged it, so I'd hope that the internals can handle
> it.

Yeah, I'm saying there may be backends which want to return matches
which have different categories.

Furthermore, I think it makes more sense to keep the match type
associated with the match itself, rather than a set of matches.

Currently your resultset code always groups matches by their types. 
This may not always be the right thing to do; that's why we should keep
the match type tied to each individual match.

> [Grouping]
> 
> >        In order for this to happen, though, we need to maintain
> >        information about the structure of the frontend object all the
> >        way through to the backend.  This is not possible with our
> >        current setup; I think it is okay to treat this as a mid-term
> >        problem though.
> 
> Hmm... I'd actually say that the problem is that you need to understand
> the frontend object, rather than just pass the data around intact.  A
> cluepacket has no idea what it's passing in today, apart from 'clues'. 
> Suspect that this is a bigger disussion.

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.

best,
Nat