[g-a-devel] Re: Bonobo - Accessibility Technology Distributed Arch.
- From: "Nickolay V. Shmyrev" <nshmyrev yandex ru>
- To: krishna vamsi wipro com
- Cc: gnome-components-list gnome org, gnome-accessibility-devel gnome org
- Subject: [g-a-devel] Re: Bonobo - Accessibility Technology Distributed Arch.
- Date: Mon, 20 Mar 2006 17:40:48 +0300
В Пнд, 20/03/2006 в 12:00 +0530, krishna vamsi wipro com пишет:
> Hi List,
> Note : Please view the mail in Rich text Format as the diagram
> is formatted using the same.
> I'm thinking of distributed architecutre for Accessibility
> technology, Typical architecture contains two m/c's.For more
> infor refer to the picture below.
> MC-1 contains the gail and the atk-bridge and mc-2 contains
> the AT-SPID and AT-CLIENT such as screen magnifier. AT-SPID
> has to communicate with ATK-BRIDGE get/put
> request.Communication is based on Bonobo/Corba Objects.
> I'm struck with two questions here...
> 1. Bonobo AF(Activation Framework) is responsible to activate
> AT-SPID, currently does the bonobo AF has the capability to
> Activate the AT-SPId on remote m/c.
> if yes, can you suggest some sites where can i get
> this help ?
> if not, are there any un-official hacks to do the
> same ??
> 2. if Activation succeeds is the bonobo capable of
> communicating with the Other m/cs Bonobo and how it can be
> Below is the pictorial representation of the what I described
First of all about 2, bonobo object should be able to communicate with
other object if activated, there should not be any problem with it.
Situation with 1 is worse. Bonobo doesn't support remote activation yet
as far as I know. But I suspect it's not hard to implement this and it
should be nice feature. I see it in implementation of new type in object
description (currently we have factory, exe and shlib there, it may be
possible to add something like "remote"). If you'll implement it, that
would be great.
As a hack I can suggest the following. On activation of binary factory
the following things are happen: bonobo-activation-server runs an
executable as a child process, creates pipe and passes --ior-fd to
child. After activation child writes IOR of Corba object back to
activation server. You can create a binary or a shell script that on
start will go to remote machine and run spid with --oaf-ior-fd, get IOR
of new object as bonobo-activation-server does. After that you can pass
that IOR from remote machine to b-a-s on local machine. Hope, that will
The full scheme if quite complicated, for example if factory executable
won't get --oaf-ior-fd, it will try to fork server and register on it,
hope, that behaviour will be cleaned someday. Probably --oaf-ior-fd can
] [Thread Prev