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

[Brad Chapman]

> We'll have to come up with a complete 'vocabulary' for _any_ 
front-end and
> for
> the middleware.  We're defining a (rather odd) API here.

Agreed!

> I was planning on getting gi to puke out some XML tags as things are 
done by
> the user.  I think this will help you see what the middleware has to 
respond
> to.  Let's work at developing the vocabulary piecemeal rather than
> all-at-once.

This makes sense, and is the approach I've been using with the other 
xml so far. I started trying to have a DTD, but I change things so 
much right now as I'm learning, that it doesn't make sense to do this. 
As things become clearer this would be something to do.

I started making the front talk to the middle via xml in the changes I 
just committed. I've started with connections, and I made the front 
send the middle the following XML:

	<front>
	  <connect>
	    <input id = 'workspace1/workspace2/container1.xml'/>
	    <output id = 'workspace1/workspace2/viewer2.xml'/>
	  </connect>
	</front>

This is just a semi-modification on what you were talking about before 
(to make it valid XML so I can use DOM to work with it). I figured 
that other actions can be a modification of this.
    Right now I'm just passing the info as a big string o' XML and 
parsing it from this. I took a little look at the httplib library in 
the python distribution, and it seems like it might be useful (at 
least, there are send and reply functions to call). Maybe I'll try 
playing with this, but as you said, I'm not positive how to do it 
with "streaming" data. We'll see, I guess...
 

>    <middle workspace_add id="blabla1"
> icon="back/private/container/locusx.icon">
> (symbol comes from knowing the locus type)
>    <middle workspace_add id="blabla1" type="processor">
>    <middle workspace_add id="blabla1" interface>
> (now the middleware gives the interface description)
>        <text value="This is a locus">
>        <okay value="Okay">
>    </middle>

What kind of information do you want the middle to give to the front? 
Would something like:

<middle>
  <connect_reply>Error: Loci cannot be connected</connect_reply>
</middle>

be sufficient. I think we should keep the chatting to a minimum since 
we have 
to deal with everything we pass. So, if you send the middle a request 
to connect it either does it and returns "Success: Loci connected" or 
send an "Error" if it cannot. Then the front can decide what it wants 
to do. How does this sound?
    Even though it is a mess to untangle them, it will be pretty cool 
to have the middle and front finally free!

Brad