[interfacekit] Re: App Registration

>  [if sending a BMessage to another app, then quit, and the other
>  app passes in the BApplication ctor only seconds later, it still
>  gets the message in its MessageReceived() hook]
> >The explanation for this phenomenon is not, as one could think, that  
> >the first application moved in time to the point where the second  
> >application has just constructed its BApplication object, delivers 
> > the  
> >messages and moves back to the original time, but that after loading 
> > an 
> >application image there is already a port available. For those who,  
> >looking at the listport output, wondered, why app looper ports can 
> > have 
> >two different names, that's the answer: A port named 
> > `rAppLooperPort'  
> >is created while loading libbe -- certainly in initialize_before() -
> > -  
> 
> Ah-ah! So that's it. I was wondering about this port 'statically'
> instantiated in libbe.so, and was totally ignorant of what the hey
> it could be about.... only speculated that it might have been
> the reason why app_server didn't link against libbe.so ...

Mmh, I wouldn't consider this to be a very strong reason. It would just 
be one wasted port. Plus three more -- the ports for synchronous 
replies. Still not very convincing, as the app server could delete the 
ports. Maybe it's indeed a problem caused by some initialization done 
by libbe, but currently I can't see it.

> Do we want to replicate this behaviour?  pros: we get to do
> the "time warping messaging" too :-)  cons: it might prevent
> us from linking app_server in a more reasonable way than  Be
> did (some of this is total speculation on my part, as you all 
> gussed).
>
> Me i'd be totally happy if the port was just instatiated once
> in the ctor of BApplication, in a rationale way.  (=> just
> my 0.02USD, or whatever currency is weak currently to reflect
> how I 'value' this rambling of mine <=)

Actually I was wrong with my assumption that the port is created during 
library initialization. I just learned, that only the reply ports are 
created at that time. My only explanation (let alone advanced temporal 
technology), how the whole things could work nevertheless, is that the 
roster creates a port when an application is pre-registered and the 
ownership is transfered to the launched application later on. Certainly 
by the application itself, after calling BRoster::IsAppPreRegistered() 
-- this would also explain, why this method returns an app_info (at 
least the port component makes sense ;-).

Yep, sounds reasonable. :-)

CU, Ingo

Other related posts: