[Pipet Devel] gui protocol revisited

jarl van katwijk jarl at casema.net
Thu Mar 23 02:32:06 EST 2000


>

Hi All,

>
> <front>
>   <add_workspace>
>     <workspace id='' >
>     </workspace>
>   </add_workspace>
> </front>
> <middle>
>   <success>
>     <workspace id='workspace1' >
>     </workspace>
>   </success>
> </middle>
>

Looks nice, one thing: you're talking about 'requests', so will the GUI (and
optional other
'controllers' like scripts or knowledge databases) have (1) the 'structure'
stored internally
or will they (2) 'build' it inside gms\overflow?

GMS uses (2), I think Loci does too, but just to make sure..


>
> So, once again, this API is XML-based and ran through a socket.  My question
> is: Should we use CORBA instead?  What are the advantages/disadvantages?  My
> MAJOR interest is that we have multiple UIs that can be attached to (and
> controlled by) a single core,

Yes, this must be possible. As I mentioned before, other 'controllers' should be
possible.
These will be non-interactive clients like scipt-interpeters and KDB's

> can run concurrently in the same session, and
> can be controlled by one-another (via the front-request, middle-approve API).
> Can we do that with CORBA?

Yes. Every 'client' requests the core for a communication line, or a ORB. After
the comm.
is setup, the client can call the functions descriped by the idl. (see the gms
source for
ADMDFP.idl, which is the GUI->CORE communication api.)

The GUI just calls a LOCAL function like:
    GUI2CORE_add_node()

which will be transported (among other things) by corba to the core and call:
    IMPLEMENTATED_GUI2CORE_add_node()

which is a function located in the core.






More information about the Pipet-Devel mailing list