Re: bonobo-activation - a plan.

[Maciej Stachowiak <mjs noisehavoc org>]

On 18Oct2001 08:48PM (-0400), Michael Meeks wrote:
> 
>         We can only possibly exit, if we have no active registered objects
> - which seems very likely: the panel etc. etc. that is unless you want to
> store / hydrate all the IORs.

That's exactly the plan (store/hydrate the IORs).
 
>         Furthermore, the server takes about a second of CPU time to start
> on my machine, so I think more impressive savings might be to look at
> reducing the memory footprint rather than a lot of work to stop and start
> it.

I'll try to reduce the startup time, however, assuming the timeout is
long enough, then applications which do a lot of activation will see
no delay. And if activation is infrequent, it doesn't matter that
much.

The reason for the server to quit is not primarily memory usage but
lifecycle issues. It can't stick around forever and the solution of
killing it on logout does not really work, as a user may be logged
into one system more than once. I'm happy to hear alternate designs
for making the life cycle sane.
 
> > Even if I were not planning this feature, it would add a race
> > condition in the case where a Java app tries to do activation before a
> > native GNOME app.
> 
>         Not if the Java stuff only works if the server is already running.

This is exactly the race condition I fear. If you have a Java app in
your session startup, this feature may or may not work.
 
> > I'd like to hear a workable design for how Java can get access to an
> > activation server before rushing to add such an interface.
> 
>         Ultimately, the best way - as you point out is to get them to bind
> to a C library with a stable interface. I would personaly prefer this to
> be the bonobo_get_object interface - since that exposes a lot of power.

That could be useful. I would rather see the varios Bonobo "Context"
intefaces activatable through the root interface in bonobo-activation,
but it's just a detail
 
> > Why is the operation called activateRemote instead of activate?
> > selection_order is a string list, not a string.
> 
>         Well - it would be better to have a plain activate, and in the
> simple case have neither flags nor a selection order; lots of activations
> are by OAFIID - especialy of the type 'Get me the accessibility daemon'.
> 
> interface Activation : Unknown {
> 
>         Unknown activate (in string query) raises ...;
> };
> 
>         But you are still left with intriguing questions about shlib
> components in the remote case - they are not possible without heavy duty
> client support code.

I'm not sure what you mean. What is the semantic difference between
your `activate' above and `activate_remote'? For simple activation by
OAFIID, there is, of course, activate_by_id which dould be a method in
this activation interface.

> 
>         It's certainly a compatible change as long as people don't inherit
> from the interface and since no-one implements it outside of
> bonobo-activation this seems very reasonable. 

Pardon me for taking a legalistic approach to binary compatibility. 

> Clearly, implementing an
> Activation2 interface inherited from it is also trivial and in some sense
> 'safer'.
> 
>         Anyway - for now Bill / Louie I think the best way to proceed - is
> to dump the IOR of the accessibility daemon that you are most interested
> in, into /tmp/orbit-$USER/reg.GNOME/Accessibility:1.0 or whatever, and
> then just pull that out in the Java bindings.

That sounds like it might work.

 - Maciej