[Adium-devl] Using NSUserDefaults for preferences (or not)
Evan Schoenberg
evan.s at dreskin.net
Tue Apr 4 20:47:04 UTC 2006
On Apr 4, 2006, at 3:41 PM, Colin Barrett wrote:
> Here are a couple of thoughts:
>
> - What if you had a separate user defaults file for each group?
> com.adiumX.adiumX.contacts, for example.
It might be better, certainly... though that Contacts group
(ByObject) is way too big to be grouped together even without the
much much smaller Accounts and global preference files. I hesitate
to clutter the user's Preferences folder with my (*counts*) 1000 or
more different contact/group/metacontact plist entries [I have 1,967
plists in my ByObject folder...]
I don't think it's possible with NSUserDefaults. The underlying
CFPreferences API probably allows it, but I haven't investigated it
much... I hate staring at CF code though we can roll that way if we
need to :)
> - Can we convert our current implementation over to binary plists?
Easily. Instead of using -[NSDictionary writeToFile:] and -
[NSDictionary(AIDictionaryAdditions)
dictionaryAtPath:withName:create:] we'd use implementations using
NSPropertyListSerialization.I'm confused by Apple's documentation on
binary plists... they flat-out recommend using XML plists (as we
currently do) and then use binary plists for NSUserDefaults. Any
idea what advantages/disadvantages are?
> - I know Evan doesn't "get my Core Data hard-on" ;), but it's too
> bad we can't use Core Data for this. Would be nearly instantaneous,
> and would probably be real fast too. Something like
> AIPreferenceProxy, but it'd be called AIManagedPreference.
>
:)
> I have a couple general questions about the prefs system too. How
> bad is it, right now? Does it need cleaning up? I know this code is
> some of the oldest in Adium, I think it's a good idea to at least
> do a small audit of the state of things in there.
It's old, but I overhauled it not that long ago ([[9134]). I've been
all over it while doing this NSUserDefaults experiment and it still
seems pretty good.
David wrote:
> ByObject will be able to get *much* smaller for 1.0. We're storing
> message history info in there, which 1.0 doesn't use.
Should be easy to filter out the message history in the upgrade code
-- I'll try that later, or you're welcome to beat me to it -- and see
what the result looks like. I'm still hesitant about using a system
which won't scale; what do we do 5 years from now when dude has
talked to 10,000 contacts and all the tiny preference data adds up.
Furthermore, a plugin tapping into the preferences system shouldn't
be able to wreck runtime performance havoc just by storing large
preference information "to disk" via AIPrefernceController.
-Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20060404/2983905e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20060404/2983905e/attachment.sig>
More information about the devel
mailing list