Re: bonobo activation question
- From: Bill Haneman <bill haneman sun com>
- To: desktop-devel-list gnome org
- Subject: Re: bonobo activation question
- Date: 06 Aug 2002 12:57:54 +0100
> From: Michael Meeks <michael ximian com>
> To: Thomas Hunger <520039486312-0001 t-online de>
> Cc: GnomeDesktopDevel <desktop-devel-list gnome org>
> Date: 05 Aug 2002 08:47:18 +0100
>
> Hi Thomas,
>
> On Fri, 2002-08-02 at 11:09, Thomas Hunger wrote:
> > I want to activate a Bonobo component on another computer using bonobo
> > activation.
>
> I'm afraid you're out of luck. I binned this mode of operation, and
> will be expunging even more of it in future, since the current design is
> buggy, race prone, unneccessarily complex, unmaintainable etc.
Hi Michael:
I am a little worried by references to your "expunging" remote
activation. We actually do rely on the ability to do this
("theoretically") via bonobo-activation, in our roadmap for
accessibility support. As you know, Sun uses and likes to promote
various network-app scenarios (and I think GNOME should too, unless we
change our name to GOME), and thus assistive technologies and
applications are not expected always to be co-resident on the same host.
I realize that we don't have a readymade way of doing this ATM, but I do
expect that this feature will be laid over the existing b-a-s framework,
perhaps via extensions to the bonobo-activation query syntax. Also, as
you recall, we eventually need IDL for running bonobo activation
queries, rather than relying solely on C bindings to
libbonobo-activation and bonobo-activation-client. So it would be good
to get the issues with the current implementation out in the open in
capsule form so we could agree on at least an API for the future.
Having sold the "remote accessibility" bill of goods I'd like to know of
any developments or plans that might affect (adversely or positively)
our ability to deliver it ;-)
best regards,
Bill
> We will re-add remote activation in future, when the more pressing
> problems of session management, i18n, multi-display etc. are handled
> more cleanly and elegantly and simply.
>
> > But it won't work this way. Can somebody help me?
>
> To get the effect you want, it's necessary to stringify the IOR of the
> remote process, and shove it into the local object directory; to do this
> on your remote server machine you need to be able to:
>
> * CORBA_Object_to_string (obj, &ev);
>
> transfer the string:
>
> * CORBA_Object_from_string (string, &ev);
>
> on the client side,
>
> By the time you've done that - there's fairly little point in using
> b-a-s, but if you want to make it available to other people, then
> register that object reference in the normal way.
>
> HTH,
>
> Michael.
>
> --
> mmeeks gnu org <><, Pseudo Engineer, itinerant idiot
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]