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

[J.W. Bizzaro]

Brad Chapman wrote:
> 
> 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!):

Great.  Fire away.

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

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.

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

Right, the middleware gives the front-end ONLY WHAT IT NEEDS TO KNOW.  When a
windowlet is opened in the gi workspace, it needs to know what widgets go in
there.  But remember our earlier conversations about this: The middleware
provides high-level XML descriptions of the interface; each front-end
interprets it differently.

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

Right.  When the gi windowlet is created, the FE will need to know what goes in
it.

> 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?)

As XML in the same pipeline as the request.

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

I think so.  Here's how I'd put it:

There is an XML description of locus X in a container.

The user uses gi to DnD locus X out of the container and onto the workspace.

    <gi workspace_add id="blabla1" location="back/private/container/locusx">
(I think the FE's knowledge of the location may be more limited.)

The middleware checks the directory for locus X of id 'blabla1', XML and
wrapper.

The middleware find locus X XML and wrapper, and puts the XML in the database. 
Being in the database, locus X is now considered 'on the workspace'.

Since this operation was successful, the middleware returns

    <middle workspace_add id="blabla1" confirmation="okay">

And since the gi got confirmation, it proceeds to create locus X on the
workspace.  This involves, of course, putting the icon, symbol and windowlet on
the workspace.  So, perhaps the middleware needs to continue with providing
this information.  It returns:

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

(Don't take my XML style as law here.)

The interface description is rather vague, but this can be interpreted
differently by different front-ends.  The gi front-end may make a windowlet
like so (using pygtk or libglade):

    +-------------------+
    |                   |
    |  This is a locus  |
    |                   |
    |   +----------+    |
    |   |   Okay   |    |
    |   +----------+    |
    |                   |
    +-------------------+

The natural language interface may come up with something like this:

    This is a locus
    Okay? > _


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

The HTTP interface will be a bit of a challenge to make, since it doesn't work
well with the streaming dialog model we're using: Web pages are static.  But I
imagine there will be a common Web page called the 'workspace', just as with
the other front-ends, and subsequent Web pages will be generated according to
actions taken by the user.  Much of the continuous dialog will have to go on in
the background unbeknownst to the Web user.

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

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.

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

Thanks.  I thought the folder icon would make us think 'Mac' more than the
cylinder would :-)

I'd like to work on making groovy icons and themes, but it would take too much
time away from programming (not that I'm hacking all that much right now).  I
know a couple artists who could help in this area.  Gary's pretty handy with
The GIMP, but his time working on the new server is too valuable.  My brother
is good too, but I have a hard time getting him interested in my projects. 
Anyway, it's something that will come with time.  Hey, if Loci takes off, we
may get a loci.themes.org page :-)

Cheers.
Jeff
-- 
                      +----------------------------------+
                      |           J.W. Bizzaro           |
                      |                                  |
                      | http://bioinformatics.org/~jeff/ |
                      |                                  |
                      |        BIOINFORMATICS.ORG        |
                      |           The Open Lab           |
                      |                                  |
                      |    http://bioinformatics.org/    |
                      +----------------------------------+