Architectural ideas to consider

[Jamin Philip Gray <jamin pubcrawler org>]

In thinking about the possibility of creating a framework in Dashboard
for creating notes associated with matches, a friend and I have come up
with some possible changes that we think would be beneficial.  The idea
is that once Dashboard has displayed matches, the user would be able to
click a button to add a note.  A dialog box would pop up with a listbox
with a list of matches.  The user selects which match he wants assocated
with the note, and enters the text.  The next time that match is
generated by a backend, a notes backend generates an additional match
which contains the note the user previously entered.  

To give a concrete example, let's say I get an email from a friend about
a project we're working on.  Dashboard will have generated a match on
the user's contact information in the evolution address book.  I want to
make a note about a feature my friend suggests for the project we're
working on.  So I add the note, associating it with the evolution
address book match.  The next day my friend sends me an IM which should
also generate the match in the evolution address book backend and my
note will appear in Dashboard.  

Here's a few architectural changes we can envision which would make this
possible:

* First of all it would be enormously helpful if each Match had a useful 
  and unique identifier.  For example:

  "bookmark:http://gnome.org";
  "IM-log:jamin47"

  This way we can store the notes in a database and use this identifier
  as the key.  The Match.Desc field could be perfect for this, except
  that most backends don't put anything useful there, the gaim
  conversation logs backend being one notable exception.  

* A new cluetype: "match".  We envision the engine cluechaining a clue
  of type "match" with the aforementioned identifier as the text of the
  clue.  We would then write a notes backend which would only listen to 
  clues of type "match".  

Aside from enabling us to create the notes architecture, the unique
identifier really feels "right" and the new cluetype "match" could also
have some other interesting uses.  You could have backends that collect
statistical data on matches generated by other backends, or observe
which matches often go with other matches.  

If people approve of these changes, I'd be more than happy to do the
work and send in a patch.  

Anyway, ideas, feedback?

-- 
name:   Jamin Philip Gray
email:  jamin pubcrawler org
icq:    1361499
aim:    jamingray47
yahoo:  jamin47
web:    http://pubcrawler.org

So Linus, what are we doing tonight?  
The same thing we every night, Tux. Try to take over the world!