GfPreferences? Explained
This was taking from an IM conversation I (grim) was having with john bailey.
(10/29/06 19:30:15) Me: the GfPreferences API will remain pretty much intact... (10/29/06 19:30:24) Me: except it's going to work a bit differently.. (10/29/06 19:30:43) Me: first off.. (10/29/06 19:31:00) Me: it'll implement a GfPreference engine that can figure out which engine a preference belongs too (10/29/06 19:31:20) Me: it will do this by use of a hash table, with the data being a pointer to the engine, and the key being the mount point.. (10/29/06 19:31:30) Me: ie, say you have network preferences on /guifications (10/29/06 19:31:45) Me: the key will be /guifications and the data will be the engine from the connection (10/29/06 19:32:05) Me: you will have to initialize GfPreferences with an instance of a preference engine to be used a / and the local preferences (10/29/06 19:33:06) Me: when you try to remove an engine from GfPreferences, it will make sure nothing else is "mounted" underneath it to avoid problems there.. (10/29/06 19:33:42) Me: anyways, to determine what engine a preference belongs too... rather than every preference having a reference of the engine it belongs to, we're going to do some mucking with the preference names... (10/29/06 19:34:15) Me: going back to the network preferences, /guifications... say we get a call to get the value for /guifications/feeds/gaim/enabled (10/29/06 19:34:37) Me: to determine the engine, we walk backwards through the path to find it's engine.. (10/29/06 19:35:01) Me: ie... /guifications/feeds/gaim/ /guifications/feeds/ /guifications/ (10/29/06 19:35:26) Me: at this point we have the mount point, so we remove the mount point from the name, and make the call on the engine (10/29/06 19:35:29) Me: make sense?
