[interfacekit] Re: BHandler::fToken

 > > It is indeed the event port of BWindow that gets the event
> messages from the
> > app_server, but they arrive as normal flattened BMessages.
>
> I'm curious: Do you know any reason for using flattened BMessages? AFAIK
> (unlike ours) the R5 app server is not linked against libbe and therefore
> has to do similar hackery as the kernel to produce those. I would
> understand this, if the messages were sent to the looper port directly.
> Any reason for not doing this, BTW?

Why would it contain hackery, why not just a copy of the BMessage class,
without unneeded functionality? This reduces the amount of code to write on
both sides, and reduces the amount of possible bugs :). Besides flattened
messages are not such a bad thing, the amount of overhead it would cause is
highly exaggerated I think.
For window/view communication a whole other command based system exists, and
there I find it justified. But for things that arrive as message, and will
be handled as a message, I think BMessage should be used, unless testing
shows it's a bottleneck.

The app_server messages that arrive on the event port have as magic 'FOB1',
which shows they're  normal flattened BMessages.

> > I will try to explain how I think it happens in R5 :)
> >
> > To begin the story, a BView is created on the client side, since it is
> > derived from BHandler, it gets a handler token, which is a
> unique identifier
> > for the BView in the BApplication. At a certain moment, it gets
> attached to
> > a BWindow (AddChild). By getting attached, it gets a counterpart on the
> > app_server. The BWindow takes care of this, by sending the
> necessary command
> > through the session port (view_builder), one of the parameters of this
> > command is the handler token.
>
> I wondered, how BView/BWindow could get the token of a BHandler, since
> neither is a friend of it, but it seems I overlooked the inline friend
> function `int32 _get_object_token_(const BHandler* )'. BTW, I'd propose to
> drop all current friends and introduce a single friend class
> BHandler::Private (similar to BRoster::Private), which bundles the
> private member access.

As long as we can maintain binary compatibility I see no problem with such
change. Otherwise we can wait until after R1. I think there's quite some API
cleanup needed once we have an R1.

> > I find this way of working very clean, and especially safe. As
> you can see,
> > only once the view was searched through the tree, and the message went
> > through the same processing pipeline as all other messages.
>
> That clears things up quite a bit. The only thing I don't understand, is
> why the message isn't sent to the looper port directly. Mmh, now I think
> about it, is it maybe because the order of other commands sent to the
> window and the messages must remain the same?

When you use two ports it's easier to give one message priority over the
other. First you process the event port, then the looper port. Also the
server window is never blocked when writing to the port, since no-one else
writes to it.

> Moreover I still wonder, whether the server token for views is really
> needed (i.e. internally in the app server). A server app local hash table
> or a global one with a key including an app ID would be fine as well.

Since all resources created on the app_server are identified with server
tokens it would be strange to use another system for views. I also think all
server tokens are in one global hash table, to allow for cleanup when an app
crashes. A server token is pretty much like a handle in MS Windows.

Marc Flerackers (mflerackers@xxxxxxxxxx)
Software Engineer

Other related posts: