[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