[openbeos] Re: Preferences/File Help
- From: "Nathan Whitehorn" <nathan.whitehorn@xxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Fri, 18 Jan 2002 13:33:47 -0600
> >> 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.
An app that doesn't function is just as bad as a crashed one.
> >> 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)
OR: TranslateBMessageToXML(what,etc.) It's really not much easier.
> >> 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.
Yes. Init time matters in some very narrowly defined cicrumstances.
This is not one of them.
> >> 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.
The same degree.
> >> 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>
> >> 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.
See my other post :) That's not really true.
-Nathan
--
Fortune Cookie Says:
It's easier to get forgiveness for being wrong than forgiveness for
being right.
Other related posts:
