Re: bonobo-activation - a plan.
- From: Maciej Stachowiak <mjs noisehavoc org>
- To: Michael Meeks <michael ximian com>
- Cc: Maciej Stachowiak <mjs eazel com>, Bill Haneman <bill haneman sun com>, Louise Miller sun com, gnome-components-list gnome org
- Subject: Re: bonobo-activation - a plan.
- Date: Thu, 18 Oct 2001 16:57:27 -0700
On 18Oct2001 07:47PM (-0400), Michael Meeks wrote:
>
> Hi Maciej / Bill,
>
> If we assume that the server will be running ( which seems totaly
> safe ), and we persuade gnome-session to jam the IOR of the thing into a
> nice environment variable; say 'BONOBO_ACTIVATION_IOR', then we can be
> sure that the thing is always running - I think this is a given as the
> desktop becomes completely CORBA-ized.
For GNOME 2.0, I was planning to make the activation server exit when
idle for longer than a set amount of time, and get restarted on
demand. So it is definitely not safe to assume it's always
running. (The eventual public activation interface would be in-proc
and therefore unaffected by this).
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.
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.
> So - we can hack up a very simple IDL interface that looks a bit
> like:
>
> interface Activation : Unknown {
>
> Unknown activateRemote (in string requirements,
> in string selection_order,
> in ActivationFlags flags)
> raises (Bonobo::Activation::ParseFailed,
> Bonobo::Activation::IncompleteContext,
> Bonobo::GeneralError);
>
> };
Why is the operation called activateRemote instead of activate?
selection_order is a string list, not a string.
> We would then need a shim - to deal with shlib components that
> Java wouldn't want in-proc; but that's not tough - that we we kill the (
> somewhat cumbersome ) ActivationResult.
I would like to hear your design for this. It's part of my long-term
plans but I think there are tricky details involved here.
> We don't in fact need the CORBA context mess, because we can
> compress that into an AID if neccessary.
I'm happy to get rid of the CORBA context (was planning to do so for
2.0 in fact, since the files that use context are private IDL) but the
information it carries is not currently conveyed by the AID (the parts
of the AID that have similar contents have different semantics). If
you think the context info can be stuffed into the AID I would like to
hear a design for how to do it. I would rather see this info in one or
more separate parameters than in the AID though.
> So - would you accept a patch to do this ? I can hack one up in a
> day if you'll take it.
I haven't heard enough details to know if I like it or not yet.
> We can expand the interface later to make it more pretty, for
> Gnome 2.2 :-)
Expanding interfaces is not actually a compatible change, so we'd have
to inherit from it, adding a bit of mess, or support both the old
interface and a new one. I'm willing to live with that though.
Regards,
Maciej
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]