[haiku-development] Re: Best way to store settings in Haiku?
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 07 Aug 2012 11:59:05 +0200
On 2012-08-07 at 09:54:00 [+0200], Fredrik Modèen <fredrik@xxxxxxxxx> wrote:
> > On 2012-08-07 at 08:18:32 [+0200], Fredrik Modèen <fredrik@xxxxxxxxx>
> > wrote:
> >> > On Mon, Aug 6, 2012 at 6:00 PM, François Revol <revol@xxxxxxx> wrote:
> >> >>
> >> >> Another option is to serialize BMessage to text, as ThemeManager
> >> does,
> >> >> but the code in there is not really robust.
> >> >> The format used comes from the format Dano0 used when
> >> PrintToStream()ing
> >> >> messages, and is actually quite alike to the driver setting syntax,
> >> >> maybe we could have a common framework doing both ?
> >> >
> >> > Having looked at the ThemeManager files, I will say they do look quite
> >> > nice and are very readable, certainly much more than dumped BMessages
> >> > ;)
> >> >
> >> > If those classes could be cleaned up and made more robust and maybe
> >> > combined with the driver settings stuff, it would probably be pretty
> >> > good.
> >> François : sound's that good?
> >>
> >> Where should it be located?
> >
> > The real question is: Do you really need it? Do your settings files have
> > to
> > be human-readable?
> No not realy..
>
> But if I use BMessage I need to store some part as [device_id]_[name of
> settings].
>
> No I have two way's of reading this.
> 1. look at what devices are connected and read BMessage that has
> [device_id]_[name of settings]
>
> 2. Read all BMessages and store them in a Dicinary type (does c++ have
> one?) and in that Dicinary read out [device_id]_[name of settings]
The STL provides std::map.
> So whitch one are preferd? 1 takes less memmory
I suspect that memory is not really a concern here.
Anyway, it seems the question is moving from where and how to store the
settings on disk to how to represent the settings in memory. The where has
been answered and using flattened BMessage is the preferred format, if it
doesn't need to be human- or kernel-readable.
Regarding the in-memory representation of the settings, using a BMessage is
possible, but somewhat inconvenient. You'll usually want to at least create
a wrapper class, so you don't have to mess with message field names in code
that just wants to access the settings. Personally I've come to prefer
dedicated settings classes that don't use a BMessage as internal storage,
but can be written to and read from BMessages. Particularly the import
method is nice, since it is a single point where to deal with invalid
values, format changes, etc.
In your case I would create two classes, Settings and DeviceSettings. The
latter would contain all settings for a specific device, the former the
general settings and the DeviceSettings objects for all devices. The classes
would have nice getters and setters, so they are convenient to use.
Furthermore they would have methods to store the settings in a BMessage and
read them from one.
An example for this approach can be found for instance in
src/apps/debugger/settings. TeamSettings is such a class and it even
contains objects of other settings classes.
CU, Ingo
Other related posts:
