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

[J.W. Bizzaro]

Brad Chapman wrote:
> 
> Right--I think this shouldn't be a big problem. I need to start
> thinking more about how to create permanent storage of xml to it can
> reopened.

I'm leaning toward using the container directories to hold

    (1) The actual programs, files, etc. (often symlinks)
    (2) Loci wrappers
    (3) And XML descriptions

As opposed to the directory structure we have now that separates wrappers and
containers.

Brad, this is part of the reason I want to see Loci restricted from accessing
anything in the filesystem.

As an example, 'ls' would have the following files in the container directory:

    $LOCIHOME/back/private/container/
                                     ls@       (symlink)
                                     ls.wrap   (wrapper)
                                     ls.xml    (xml description)
And maybe also
                                     ls.icon   (icon for workspace)

But the workspace will only 'show' the processor 'ls' in the container.  The
others are hidden.

> This is a neat idea, but might be hard to keep track of, both
> programmatically and the user. I know that if my icons could be made
> invisible I would forget about half of them and end up with all kinds
> of "invisible" junk that is just taking up space. But maybe that's
> just me...

Well, I was thinking that the popup menu would keep a list of invisible loci.

> >    <middle locus_select id=387hwj7843>    middle approves
> 
> I remember something about this from before, but I'm not positive that
> I completely get it. Which events on a workspace will generate this
> kind of xml dialog?
>     Everything? (ie. selects, moves, etc...)

No, not everything.

> It seems to me that
> things like this would be better left to the front end and just leave
> the middle to deal more with issues that involve more "permanent"
> changes (like connections).

That's exactly right.

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 am just worried that a lot of talking
> between front and middle might slow things down, but then again, what
> do I know about speed issues?

I imagine the dialog would proceed at a human-readable pace for even the
busiest sessions.

>     Also, I wonder why we need this kind of dialog--why can't we just
> talk back and forth in python? It seems like even with a web
> interface, you'll have to have some kind of language generating the
> tags and recieving the responses, and why not make that python?

Because...

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

> The idea is *really* cool, but I just worry about the implementation
> time for an xml communciation pathway like this. Wouldn't this be a
> lot of work?

I don't think so.  We'll need an input queue and maybe an output queue, but
otherwise we're dealing with print statements (or the equivalent).

> It seems like with all of the separation between middleware and
> frontendware beginning to become clearer in my mind it might make
> sense for me to focus more on middleware work (which needs *a lot* of
> work), especially since your ToDo stuff is focused on frontend stuff.
> This is a fine arrangement for me--who needs to look at pretty
> pictures while they're programming? Certainly not me :-)

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.

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