[Adium-devl] ByObject prefs suck

[Colin Barrett]

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