[Adium-devl] ByObject prefs suck
timber at lava.net
Wed Dec 6 23:57:47 UTC 2006
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.
More information about the Adium-devl