Re: bonobo-activation - a plan.

[Bill Haneman <Bill Haneman sun com>]

>> > 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 consider this a non-issue for 2.0, and one that can be solved in a 
reasonable way in 2.X.

>> > 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
                                    ****  [Louise ;-) ]
                                    
>> 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.

It's unattractive for us for a number of reasons.  For one thing, we 
definitely do *not* have a guarantee that our accessibility daemon is running, 
that's why we're using bonobo-activation :-)

We also are not (longer-term) guaranteed to have the /tmp/orbit-* filesystem 
handy from the JVM's perspective.  We also have a number of bonobo interface 
which we'd like to access from Java, not just Accessibility/Registry:1.0, and 
the registry does not provide access to these other interfaces (since that 
would be redundant with bonobo-activation).

Having agreed to use bonobo in our design, partly at the urging of the 
community, we'd like to be able to access it ;-)

THanks,

Bill

> - Maciej
>

------
Bill Haneman x19279
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland