[Adium-devl] ByObject prefs suck

[Colin Barrett]

On Dec 7, 2006, at 12:34 PM, Evan Schoenberg wrote:

> On Dec 7, 2006, at 11:46 AM, Colin Barrett wrote:
>
>> I just had an idea about this: What if Events moved into a separate,
>> SQLite or CoreData db? This might facilitate creating a more powerful
>> events interface. A relational db seems like a good choice for an
>> expanded events system to me.
> Could you expand a bit (pardon the pun) on what a relational db  
> might give us in terms of the events system which the current system  
> doesn't

Off the top of my head: better filtering and searching performance  
over a large number of contacts. Filtering I mean narrowing down the  
list of events (i.e. just the events for contact X or event Y).  
CoreData would work too, and then you could do all sorts of fun stuff  
and have an iTunes or Finder like UI for searching events.

This probably could be extended to creation and firing of events as  
well? An NSPredicate could allow us to construct a pretty complex rule  
set with boolean logic (if they sign on AND it hasn't been 5 minutes).  
It could also allow the creation of general rules, which, combined  
with some sort of tagging system, could be pretty powerful, although  
all the examples I can think of off the top of my head are really  
basically just group events -- open a new message window when a  
contact signs if they are tagged "important". Combining that with  
boolean logic might be useful (people important and in group school  
get one soundset, school gets another, etc).

I totally reserve the right to look back on this and say it was  
totally nuts. I definitely haven't thought this all the way through (I  
point out the "just had an idea" phrase in the original message :P).

Who knows, if we make the events system powerful enough, we might even  
be able to convert code into just events that fire actions. We'd need  
a way for plugins to hide events like that from the user, but it would  
be good.


>>  It's very rare that you're actually going to  add another event  
>> type.
> Right now, plugins can add any sort of event, which I believe is  
> potentially very useful.

Add any sort of event or event *type*? Type would be Contact_Signs_On  
or Contact_Is_Seen or something like that.

If you set up the database right, this could still be done.

Have a table called EventTypes, or some such. Since good DB design  
prefers using generated (e.g. "id = 1") and not natural (e.g. "Evan  
Schoenberg") foreign keys[1] whenever possible, adding a new event  
would be just adding a new row to the EventType table, and then you  
could reference that event type by its id number.

A gotcha would come up when you delete an eventtype (it's not as bad  
as you might think, the ids don't get re-used), and then try to fire  
an event with that eventtype_id, but I don't know how that would even  
work in the current code, so...

Also, reaching back a bit, wouldn't this technique allow plugins to  
add fields for a byobject replacement?

-Colin

[1] to designate a column as a foreign key means that you're telling  
the database that it's actually the key for another table somewhere.