[Pipet Devel] Peep update

[J.W. Bizzaro]

deanne at density.biop.umich.edu wrote:
> 
> 1) Accept input from peep thru CORBA. This input will be (loosely), "User
> wants [xxx] node in [yyy] position" where "xxx" includes type of node and
> name of node, and "yyy" includes network-order and URI of node.

Yeah, or "Do this with that".  (I think the syntax of the Tcl scripting
language would be good for you and Brad to take a look at.)

> 3) Regurgitate everything the UI has fed it, on command, so that the UI
> (peep) can form a nice, tidy list out of the information.

And this is important (maybe more so for Pied than Peep): The UI never really
does what the user says, only what the DL says.  This is not only for error
checking, but it allows one UI to be controlled by another.

> 1) Act as a "sanity broker" to the DL so the DL always gets something it's
> expecting.  I've chosen to use the Cmd.cmd class which simply doesn't
> accept input unless it matches our internal "list" of commands.

Good point.  But this may be more important for Peep than Pied ;-)

> 3) Take regurgitated DL information and arrange it in a neat, referential,
> and tidy way so users can easily manipulate it at the UI.

Yep.  You'll largely be stripping off the XML tags.

> How peep feeds information to the DL
> 
> As I see it, peep could feed info to the DL in two methods:
> 
> 1) Dynamic and Transparent. Peep would automagically execute an update to
> the DL every time a user defines a pnode, etc. This is nice for run-time
> tweaks, I guess. It's dynamic because it automatically updates. It's
> transparent because it gives the DL the job of handling the structure of
> the network...in this case, the UI is "transparent" to the DL, and is
> simply acting as a real-time  information broker to the DL during its use.
> Pros: Dynamic updating to the DL.
> Cons: All the work is done by the DL, the UI is just the interface to the
> DL. Therefore, the DL will have to notice when shite does not make sense.

THIS /IS/ THE METHOD WE WANT.

> 2) Static/Opaque. Peep would allow the user to define the entire network
> (or pieces of it) and store all the information locally in and with the
> UI. It would only "inform" the DL when the user selects to 'execute' at
> which time the DL gets all of the UI information all at once. This is
> static because the UI only accesses the DL when the UI is ready to, based
> on what the user says.
> Pros: All the "playing" in the network is done in the UI. The DL isn't
> ever "bothered" until the structure is built and any craziness is handled.
> Cons: The UI is now less of an interface to the DL than a
> structure-builder in its own right. It duplicates some of the
> functionality of the DL and is probably going to be "bigger" and less
> sleek.

THIS IS /NOT/ THE METHOD WE WANT.

> My choice is #1, for the following reason:

Whew.  Good :-)

> I believe that any program which utilizes piper as part of its execution
> (like GeneGnome will) would like to have piper's DL do all the figuring
> and have its UI/Code Interface simply feed information back and forth. If
> we believe in seperable UIs, then the UIs should only be the *interface*
> to the DL, but not expected to do much more than check for validity in
> some very simple ways.
> 
> Yes, no, thoughts?

By George, I think you've got it! :-)

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