Re: [GD-General] A portable preferences library

[Brian H. <ho...@py...>]

> Are you thinking the preferences library will be portable enough to
> work for consoles too?

No reason for it not to.  

The general architecture is that you open and close prefs, and when 
you open you can specify if you want them user-level, system-level, 
and whether you prefer a filesystem implementation instead of a 
"native" (Win32 registry and OS X Preferences) implementation.

Obviously, I'm not going to write a PS2 or GC implementation, but the 
API is so simple that layering it should be trivial.

You query a value using an API like PrefLib_GetFloat( "name", &f ), 
etc.  These then dispatch into a portable thunker that converts to a 
canonical little-endian format, and then call the system dependent 
PrefLib_WriteBinary() implementation.

My Win32 implementation is complete, and I'm about 50% complete with 
the filesystem implementation which, in theory, should just work on 
Linux.

To make this manageable, I'm not going to support things like nested 
keys or arbitrarily large data chunks (i.e. movie files, screenshots) 
although I won't prevent people from doing the latter.

> Also, I assume most people don't read/write preferences often, but
> I was wondering if your library would have the concept of loading
> all the prefs in the beginning, then reading/writing them in
> memory, then finally flushing them back to non-volatile storage
> when done?  The reason for this is that memory cards have a limited
> lifespan and are slow to access anyway, so being able to read/write
> to storage only once is a good thing.

Interesting that you should bring this up, because I had to deal with 
this last night.

There's a bit more bookkeeping to doing a purely in-memory system, but 
there are also a couple ugly pitfalls:

1.  Multiple processes accessing the same pref file can clobber each 
other.

2.  The need to flush periodically so that if the app terminates 
unexpectedly, any preferences are not lost due to the crash.

For these reasons, the file system implementation I'm doing is 
actually slow but safe.  Every access forces a file read/parse, modify 
in place, and then a write back out.  Yes, in theory that's amazingly 
slow, but I expect that A.) it won't be that big a problem since 
developers rarely thrash preferences and b.) if it is a problem, I 
expect that developers will end up caching values in memory anyway.

All that said, a memory card implementation could easily cache all the 
data behind the scenes and only flush when PrefLib_ClosePrefs() is 
called.

Brian