[openbeos] Re: Preferences/File Help
- From: "Nathan Whitehorn" <nathan.whitehorn@xxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Thu, 17 Jan 2002 14:55:41 -0600 (CST)
> 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:
