[Adium-devl] ByObject prefs suck

[disposable at infinitenexus.com]

You could just as easily filter using an array controller and an  
NSPredicate without need for an entire relational DB. This would also  
necessitate an odd 'bridge' in which the non-DB code/data must  
interact with the DB-code/data and that too will increase maintenance  
cost. I apologize if I seem like a pessimist, just throwing out points.

- brian 'bgannin' ganninger


On Dec 7, 2006, at 12:22 PM, Colin Barrett wrote:

>
> 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.
>
>
> _______________________________________________
> Adium-devl mailing list
> Adium-devl at adiumx.com
> http://adiumx.com/mailman/listinfo/adium-devl_adiumx.com
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20061207/e8adaf97/attachment-0001.html>