Re: bonobo-activation - a plan.

[Bill Haneman <bill haneman sun com>]

Maciej Stachowiak wrote:
> 
> 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.

Actually it does not, for reasons that I have already detailed.  We
don't have a 'single service' that we are interested in - except perhaps
the bonobo-activation service itself ;-)

We really need to have a non-JNI, non-C-bound way of querying
bonobo-activation.  It makes sense to do this via IDL for the activation
service, and I think we should agree to do this in principle as soon as
possible.

I am comfortable making this a "non-public" interface (that is, a
'consolidation private' one) for now, and deciding later on what we want
to expose in a sanctioned way.  But in the meantime we (accessibility
work) need a way to query this from a Java VM without using JNI, or
relying on reimplementation details as with monkeybeans.

As for the bootstrapping of an 'idle' activation server, we can easily
add a startup/bootstrap call to the 'java' script, since JVM invocations
are normally started via scripts and not by directly invoking the VM's
binary.  That way we can be assured that the activation service is awake
when we make the Java accessibility bridge calls (which happen very
early in the Java application's lifecycle).

Best regards,

Bill

>  - Maciej