[openbeos] Re: Preferences/File Help
- From: John Tegen <john.tegen@xxxxxxxxxxxxxxxxxx>
- To: "'openbeos@xxxxxxxxxxxxx'" <openbeos@xxxxxxxxxxxxx>
- Date: Thu, 17 Jan 2002 14:16:13 -0800
$0.02:
I totally don't see a need for a preference server. Storing a retrieving an
applications preferences takes a "nano-second", and only occurs twice during
an applications life cycle (typically). It does not warrant a server to be
available all the time, taking up resources. Most likely it can be apart of
an existing kit, so dynamical loading is a non-issue.
Plus, I would hate for my application not to work and save its preferences
because the pref server is down. The end-user would not appreciate their
settings being lost.
Flattening a BMessage to a file is a trivial exercise. Making certain all
apps store the settings somewhere under /config/settings is probably more
important.
-- John
-----Original Message-----
From: Nathan Whitehorn [mailto:nathan.whitehorn@xxxxxxxxxxx]
Sent: Thursday, January 17, 2002 12:56 PM
To: openbeos@xxxxxxxxxxxxx
Subject: [openbeos] Re: Preferences/File Help
> Server advantages:
> Multi-threading is easy (send an asynch BMessage)
But you have to catch it later. For things responding, often it is
sync, or there is complex async receive code. No harder than a shared
lib.
> Code is seperate from yours
This is an advantage, why? If it crashes, you are still dealing with th
einability of your app to function. Look what happens to net apps when
net_server crashes.
> Accessible easily from scripting languages
How so? If I'm translating a BMessage into XML, I have to tell the
scripting language what a BMessage is first. Also, most scripting
languages can talk to C symbols in a ... shared library, but may not
know about messaging.
> Any initialization time can be shared easily (the example I did for
> the newsletter with the dictionary is a good example)
This is true. But we were talking about flattening BMessages and
getting preferences, were we not? Init time is nil.
> Easily extensible without recompiling any clients
How so? Extension is impossible without either telling the clients, or
having a config interface. Shared libs can read config files just as
well as servers.
> No FBC issues
If the client interface is encapsulated in a class, there are FBC
issues. If not, there would be none in a shared lib either.
> Library advantages
> No IPC time
> No time to stuff/unstuff a BMessage
> Ability to subclass
> Kit advantages (Server + Client stub)
> Really all of both. You can have libraries do the quick and easy
> stuff, and servers do the heavy lifting.
This is *not* a Kit. A kit is a collection of interfaces. The Device
Kit is a serverless Kit, as is Translation, Support, and Storage.
Surely you wouldn't argue a server for those?
-Nathan
--
Fortune Cookie Says:
Just about every computer on the market today runs Unix, except the Mac
(and nobody cares about it).
-- Bill Joy 6/21/85
Other related posts:
