[openbeos] Re: Preferences/File Help
- From: "Michael Phipps" <mphipps1@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Thu, 17 Jan 2002 22:14:38 -0500
>> 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.
There may or may not be an advantage here. It all depends on how your
app is configured. But you do have a point about having to catch it
(which can be a pain).
>> 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.
It runs in a different memory area. Loose pointers can't squash you.
>> 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.
Easy - if I want to write a scripting language, I can write one mapping of
BMessage, then within the scripting language write modules that send
the right protocol to the server. Prime example - awk. I could add an awk
command of the format:
returnArray=SendBMessage(toWhom,what,parameters...)
Then implement the whole BeOS API accesses in AWK completely. Example:
returnArray=SendBMessage("xmlServer",TOXML,previousReturnArray)
>> 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.
You asked what the advantages are. I listed all of those that I could think of.
>> 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.
Nope. I can add functionality to a server all day long and never rebuild
any clients. That is also true, to some degree, with shared libs, though.
>> 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.
That is assuming a client interface. I was talking about "pure" servers.
>> 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?
There are serverless kits, yes. I think of kits not as abstractly but more
concretely.
IOW - most of the time a kit is a server and a shared lib. Really a difference
in
perspective.
Other related posts:
