>> 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.