[interfacekit] Re: BRoster

> I had a closer look at the BRoster header file and annotated the
> methods with hopefully useful comments -- basically functions that can
> be used for the implementation and, where communication with the
> registrar seems to be nessecary, a message format.

Nicely done :-)

> Has anyone already thought about how to deal with single/multi launch
> applications? I currently have no concrete idea. 

Ignoring you question for the moment :-), do even know of any examples of 
B_MULTIPLE_LAUNCH or B_EXCLUSIVE_LAUNCH programs? Unless I'm looking in the 
wrong place (which I may be :-) -- it's the BEOS:APP_FLAGS attribute of the 
executable, isn't it?), every app I've looked at so far has been 
B_SINGLE_LAUNCH. Not that we couldn't make our own for testing, but...

> Somehow this must be done in the (early?) registration phase, 
> I guess. I'm not sure though.

It seems to me it would need to be handled even before the application was 
launched. I'm perhaps naively assuming that BRoster::Launch() is the only 
application launch point in the whole system (load_image() aside, which I 
assume would only be used in special circumstances, and further would not 
be concerned with B_*_LAUNCH flags). 

My first guess would be that the registrar has a list of running (and 
registered?) applications, with an app_info struct (or something similar) 
for each. When BRoster::Launch(), or more likely 
BRoster::xLaunchAppPrivate(), gets called, it would do the following:
 
+ B_MULTIPLE_LAUNCH -- Just launch away no matter what. 
+ B_SINGLE_LAUNCH -- Ask the registrar if any of the running apps has an 
app_info::ref field that matches that of the executable you're considering 
launching. If so, don't launch and send the launch messages to the already 
running app; if not, launch. 
+ B_EXCLUSIVE_LAUNCH -- Same thing as B_SINGLE_LAUNCH, but check 
app_info::signature instead.

-Tyler

Other related posts: