[openbeos] Re: Preferences/File Help
- From: Michael Noisternig <michael.noisternig@xxxxxxxxx>
- To: OpenBeOS List <openbeos@xxxxxxxxxxxxx>
- Date: Thu, 17 Jan 2002 11:55:41 +0100
"Michael Phipps" <mphipps1@xxxxxxxxxxxxxxxx> wrote on 17.01.02 03:41:26:
>
>>> >I have even thought about a server, where you send
>>> >it a BMessage, and it sends back a BMessage that contains a string
>>> > which is
>>> >an XML representation of the BMessage. :-)
>>>
>>> A server??? Better is a library, no?
>>
>>Seriously, what is the obsession with servers? IPC can be really slow.
>>If you can do it locally, why not? Servers also eat up unnecessary RAM
>>and processing power. There's a reason there are no device or
>>translation servers, you know.
>>-Nathan
>
>Obsession? No.
>Let's do a little comparisson. I want to start off by saying that I don't
>necessarily favor one over the other.
>Also some assumptions - we are using intelligent shared libraries
>
>Server advantages:
>Multi-threading is easy (send an asynch BMessage)
>Code is seperate from yours
>Accessible easily from scripting languages
>Any initialization time can be shared easily (the example I did for the
>newsletter with the dictionary is a
good example)
>Easily extensible without recompiling any clients
>No FBC issues
>
>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.
I'll add to the server advantages:
- prioritizing incoming requests
- scheduling resources to prevent thread starvation
and to the library advantages:
- no time for context switches
Now looking at the list I see no reason to take a server for a BMessage<->XML
converter.
P.S. Why don't you make everything a server??? ;-)
Other related posts:
