[Pipet Devel] J.W. Bizzaro; TODO 20000218

[Brad Chapman]

> Whenever something is 'done' by the front-end that needs to be 
communicated
> to
> the middleware (e.g., connections made/broken), an XML tag is 
generated much
> like the comments tags I just implemented.
> 
> Do you see how the comments <!--comment--> are spit out by the 
workspace
> now? 
> The XML commands will appear in the same stream.  It's very simple.

I just finished revamping the xml and starting to get the front and 
middle apart, and I'm having a better feeling for your idea and I'm 
going to start gunning for this communication method asap. I've got a 
question about it, though (of course!):

How "dumb" is the front end? What things exactly should it be doing? 
The sticking point that I'm having right now is trying to figure out 
what the jobs of the front and the middle are in filling a container 
with gui info. 
It would make the most sense to me if the front end were able to parse 
xml files  (so it can build the gui representation of a container 
itself--like it does right now). So, if I'm thinking of things right 
we'd have the following dialog:

FE = front-end  M = middle

FE: (Needs to get the info for a container on the workspace)
<info_request lociId = 'workspace1/workspace2/container1.xml'>

M: (Recieves request, then grabs everything in the container tags from 
the xml file and sticks it into a new xml file)
Return the information (somehow--as DOM? as a link to an XML file? as 
the XML itself?)

Or something like this... Am I on the right track here? 

>    (1) We want to allow front-ends to be made in languages other than
> Python.
>    (2) We want to be able to use standard IPC protocols like HTTP.
>    (3) We want a 'transcript' that can be read back by Loci and 
humans.

I will admit that I don't know *anything* about how http works, or 
even the first place to get started (maybe Gary can give me some 
clues?) but for right now I'll have the communication go on via a 
reciever and sender class on each side, and then I can start to 
incoporate http later.

> I have much more fun (and that's what this is all about) with human 
interface
> design than middleware design.  And since we have 2 cooks and 2 
pots, it's
> probably best that we each choose our favorite to cook with.

    I'm working to make a clean split right now, and then I'll build 
up the middleware so it can do a lot more than it currently does right 
now. I actually managed to draw out a picture of Loci 
intra/inter-communication on a piece of paper, so I think I have an 
idea of what needs to happens and feel fairly focused right now. Of 
course, things will probably get blurry for me really quick...
    Anyways, my artistic skills are next to zero, so I should 
definately be kept as far away from GUIs as possible.
    BTW Jeff, I like the new container locus backrground!

Brad