> 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.