[Adium-devl] ByObject prefs suck

[disposable at infinitenexus.com]

Wouldn't converting to a db-backed system add the inherent overhead  
of the dbms? As is we only incur read/write penalties and it might  
not look pretty [and needs some cleanup, as is being discussed.] In  
addition, as David alluded to, adding new values requires schema  
migration and checking, which is more overhead and maintenance. A  
final caveat - we have to either choose the lowest common denominator  
[i.e., whatever is present on all systems, guaranteed] or we bulk our  
binary size with another component.

Those notes aside - Colin, could you please articulate how exactly  
such a move is a windfall versus the costs associated with it?

- brian 'bgannin' ganninger


On Dec 6, 2006, at 5:57 PM, Colin Barrett wrote:

> On Dec 6, 2006, at 1:10 PM, Augie Fackler wrote:
>
>> [disclaimer: this is my reading day between classes and finals, and
>> my email ended up being a weird stream-of-consciousness event.
>> Continue at your own mental health risk.]
>> While trying to track down a weird bug today, I noticed my ByObject
>> prefs were freaking huge: 2,030 or so ByObject prefs for *just*
>> contacts, not including groups (including metas though).
>> I nuked all non-group ByObject files and let them regenerate, and now
>> the folder has 288 items in it, of which 23 are groups.
>> Clearly, we're storing ByObject prefs we just flat out don't need.
>> So what I'd like to do is figure out what the ByObject prefs are
>> storing for each contact, and attempt to find ways to store the
>> important data in something that's not ByObject so we could make
>> ByObject files be deleted if they're no longer needed.
>> What I've figured is in there now is:
>> 1) Preferred account
>> 2) Spelling Language
>> 3) Events
>> 4) Local alias (?)
>> 5) Old message history
>>
>> 5 can just be forgotten about with XML logging. I think we already
>> don't use 4, but I want to be sure. 2 is definitely something we
>> should save, as are preferred account and events.
>> That said, I think it might make more sense to store one large file
>> rather than lots of little files, since we're looking at about 2k
>> files with an average size of .5 kb, that's about 6 wasted megs of
>> disk space for a bunch of files that themselves shouldn't take more
>> than 1 meg.
>
> SQLite and/or CoreData and/or BerkelyDB and/or something other than
> plists would be perfect for this. Aside from using text files, what we
> have now is a pretty terrible way of doing it, so pretty much anything
> would be an improvement.
>
>> Events I think it might make sense to store in a dedicated events
>> preference location - and then include a more complete events editor
>> that lets you see all of the configured events (sound notifs,
>> everything) so that events for no-longer-listed buddies can be
>> deleted (for example, custom sounds for a particular buddy) - or at
>> least more easily purged.
>
> This would be awesome. Our events interface is already a bit
> overwhelming though, so we would need to be quite careful when
> designing it. Our current one could use a lot of work.
>
>> I don't really see a need to store special events for unbuddied
>> people anyway, so maybe it'd make more sense to just nuke events
>> associated with a particular ListObject when that ListObject is
>> deleted? Maybe we could do that with writing direction and last used
>> spelling language too? Preferred account?
>
> What about for people who aren't on your list, but you still want to
> do send later for? That's powered by the Events system.
>
> -Colin
>
> _______________________________________________
> 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/20061206/9e18ce63/attachment-0001.html>