Re: New addressbook backend.

[Nat Friedman <nat novell com>]

On Sun, 2004-02-01 at 04:07, Jim McDonald wrote:
> [...]
> 
> > When this is working, I'm ready to do a release.  Post 0.1, I want to
> > spend some serious time cleaning up the architecture.  Some of the new
> > resultset stuff is confusing and makes writing backends harder, and the
> > fact that match rendering is now uniform no matter the match type is
> > somewhat suboptimal for the user; different types of data shouldn't
> > look the same.
> 
> In what areas do you think that the resultsets API is confusing?  I'd
> hoped that it made backends easier, not harder, to write.

I think you're on the right path; I didn't mean to come across as wholly
negative.  Here are my comments:

        * The rename from BackendResult to Result is good.  I'd go
        further and call a Result a Match; as far as I can tell from
        your code, this was the intent, and it seems to map everywhere I
        see the Results being used.  So Result -> Match, ResultSet ->
        MatchSet, etc.
        
        * Matches should have types, so that you can map a type to a
        renderer:
        
        	Match m = new Match ("BugzillaBug");
        
        A renderer can then register itself for BugzillaBug matches:
        
        	RegisterRenderer ("BugzillaBug", RendererClass);
        
        We can someday have a generic set of renderers that are split
        out from the backends, but this way backends for new types can
        still ship a single file which contains the renderer, and
        registers it in the StartUp method.
        
        If you don't specify a type for the Match, you go to the generic
        renderer that you have now in gui.cs.
        
        For now renderers will just return the HTML of the rendered
        match, and can hookup to provide the images themselves; in the
        future they can return widgets, when we get to that point.
        
        Putting the match type in the match itself instead of using the
        backend category makes backend authoring more flexible, since
        you can return multiple types of matches in one backend.
        
        We should have a file doc/matchtypes.txt with all the match
        types people create renderers for, just like with the cluetypes.
        
        * Match fading.  I'm glad you are thinking about this.  We need
        to get the match grouping and relevance filtering working better
        before we can tune the fading, though.
        
        Having match types will make grouping easier since we can
        cluster all of the matches of a given type in one area.
        
        Getting relevance-based filtering working is a matter of
        tuning.  Right now almost all backends return the same level of
        relevance for a given match, and there is no relevance
        attenuation happening when we cluechain.  Both of these need to
        get fixed, and that will be a gradual process.
        
        Grouping is fundamentally harder than it looks, and I am sure
        will require a rethink of the engine at least once.   Here's
        why: It is possible that your frontend active object will have a
        structure of its own which should be reflected in the order of
        the matches in the dashboard.
        
        For example, if you are viewing a calendar with three
        appointments in it, you may spawn two matches related to
        appointment #1, two related to appointment #2, and one related
        to appointment #3.  
        
        It would be really good to know in the dashboard which matches
        came from which appointments, even in the presence of
        cluechaining.
        
        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.
        
        * Coding style.  Do you think you could make your code look like
        the rest of the dashboard code?  Your stuff is absolutely great,
        but the formatting doesn't match.
        
All that remains for a release to go out is that we get the Evolution
EDS backend working.  I'm ready to release as soon as that happens.

The next *big* project post-release is to get focus handling working
properly, so that we can all begin to use dashboard on a day-to-day
basis.  If anyone is interested in tackling this, I can writeup how I
think it should work.

Best,
Nat