[Pipet Devel] Peep update

[deanne at density.biop.umich.edu]

I spent some time talking with Brad on Sunday about the DL and peep.

As I understand it, the DL will, exclusively:

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.

2) Store information on the structure of the user-defined network
according to what the UI has fed it. This is not only dynamic storage but
also filesystem-storage so it can re-inform peep in case of local
crashes or exit of program.

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.

---
The UI (peep) will, exclusively:

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.

2) Feed the DL information. HOW this is done is still up for debate (see
below).

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

---

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.


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. 

----

My choice is #1, for the following reason:

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?




Deanne Taylor		        	     Biophysics Graduate Program
lilyth at umich.edu				University of Michigan
http://www.umich.edu/~lilyth		              Ann Arbor