[Pipet Devel] gui protocol revisited

[Brad Chapman]

Jeff wrote:
> Okay, but I guess Brad wants to keep GUI-to-core communication as a
> datastream.  Brad, will you be attaching the Loci middle to this GMS 
API?

    Well, I wanted to attach it to the idl I sent out yesterday. I was 
hoping that we could work on this and make it a standard general idl 
for communicating between the gui (which we have implemented as the 
replacable front gui and the small middle communicating via xml data 
streams) and the processing engines. Of course, the idl is not very 
good and is just what I randomly thought up, but I was hoping we could 
work from that to create a more general idl which is based on the 
starting point I sent out.

Jeff wrote:
> I'm a little confused about this 'processing part of the program'.  
Is this
> something GMS or Overflow has now?  Is it something you'll have to 
write? 
   
     I'm not really very clear right now how GMS and Overflow will 
combine and work together (I'll need to dig more into the code to know 
this for sure) to make the generalize "processing engine" that I have 
been talking about, which is why I've been referring to it so vaguely. 
As I said, I'd like this combination of GMS and Overflow to wrap into 
one idl (the one I sent out).
    Along these lines, I'd like to try and dig more into Overflow and 
GMS code and start working with it. This will probably help us firm up 
the communication between the 'middle scripting engine' and the 
'processing part' and help get the idl straightened out and all. So... 
I was going to throw myself out to the wolves and ask if Jarl and 
Jean-Marc and Dominic have parts of GMS and Overflow that they'd like 
me to work on/with, to help towards our integration goal. These can be 
small short term projects or whatever, but I'd like to help in this 
regard, and it would help me be more familiar with what is going on 
and actually be able to make more non-vague suggestions :-) 
    So could we work something like this out?

> How does this relate to the
> 'processing' part?  Perhaps you can explain this to the others and 
how we plan
> to use XML.  Will this be replaced by a DOM structure?

Well, in the idl I'm passing the XML representation (more on this 
below) as a string right now. I'd like this to be passed as DOM 
eventually, but 4Dom doesn't support this right now (supposedly it is 
coming soon) so it isn't really an option right now.
  
Jeff wrote:
> > The others probably don't understand what we mean by 'XML 
representation'.

Jarl wrote:
> The dataflow structure?

Right-o! When I say xml representation I'm just again defining a vague 
term to represent the way that nodes/loci are linked together in XML. 
The form of this needs to be worked out explicitly so that the 
'processing part' can take this xml and convert it into a form that is 
useful for it to go through and do things. When we can hash out 
this representation, then I can change the middle scripting part so 
that it delivers this XML in the right format.
  
    I think we sort of have a design down, although at least in my 
thinking, the XML representation, the makeup of the processing engine, 
and the 'middle scripting engine' and 'processing part' idls are the 
most important things we need to tackle in terms of internal structure.
    
Brad