>> It runs in a different memory area. Loose pointers can't squash you.
>
>An app that doesn't function is just as bad as a crashed one.
Maybe. I would rather have my app (that I wrote, say) not squashed by
someone else's loose pointers. Even if the action didn't work,
that would be better than a "core dump"
>> 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)
>
>OR: TranslateBMessageToXML(what,etc.) It's really not much easier.
You missed my point, here.
I am saying that I, as the person theoretically adding BeOS API calls to awk
could implement the SendBMessage function AND THAT FUNCTION ALONE
in awk. I would then have access to as much of the BeOS API as was available
from the server.
OTOH, everything that is in a .so, I would have to add to the grammer
explicitly.
Or, at the very least, make a mini-server emulation thing.
>> You asked what the advantages are. I listed all of those that I could
>> think of.
>
>Yes. Init time matters in some very narrowly defined cicrumstances.
>This is not one of them.
Agreed. I just listed out every advantage that I could think of.
>> >> 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.
>
>Indeed. You could also have a single ioctl() like function in a shared
>lib, which, IMHO, is a huge PITA>
Umm. DispatchMessage? Basically the same thing as ioctl, except it
has what instead of cmd.