[Pipet Devel] executing a network script

J.W. Bizzaro bizzaro at geoserve.net
Wed May 3 22:49:08 EDT 2000


Pipers,

I'm moving this conversation Brad and I were having about the actual execution
of a network script.  Brad was wondering how the UI would manage this and what
would be sent from the UI to the DL.

Brad Chapman wrote:
> 
> Network info is
> sent to the dl gradually, as things like additions and connections
> occur. So when the front says execute, and sends a list of loci to
> execute to the middle, the info describing the user interface wfd is
> already present in the dl (stored in xml), and so the dl just needs to
> assemble this info into a form that it can present to the bl.

Zactly.

> > BTW, we can call them nodes :-)
> 
> Yick, node is already taken by dom--especially since they have a Node
> class and everything. We'll need to think up something creative to
> refer to them as (but not pipers :-).

I suppose the developers of Piper are "Pipers" (or Pijpers ;-)), just like the
Loci developers were "Locians".

Seriously, this was brought up a few weeks ago.  If pig-dog languages like DOM
must hog the namespace of common terms, we'll have to come up with something a
little different.  I think we can just prepend "piper" to the names and use...

    piper_node
    piper_pipe
    etc.

It'd be good style to do this as much as possible, so that we have a unique
namespace.  What do you guys think?

I also have a related question: Should we distinguish (in name) between a BL
node and a PL node?  They are very different.

> You're right, the front really doesn't have any knowledge of the wfd
> connections etc., and the API for passing stuff to be executed is very
> simple-minded right now--I just have the front pass a list of all the
> loci invovled in the WDF, and let the middle figure out the
> connections and stuff. _Hopefully_ this will work...
>     Basically, I just wasn't sure the right way to select a bunch of
> loci (wait, do we call them pipers now?) and then submit them. I
> didn't know if we should:
> 
> 1. just have 'submit wfd' type button that basically submits the whole
> wfd at once, or
> 
> 2 if we should allow people to select specific loci and then submit
> them (and have a separate 'submit selected wfd' button:
>     But then, how should they be selected?
>     a. Via a big box that you drag to select everything in it.
>     b. Shift-button-1 type clicks.
>     c. Both of the above
>     d. A different method.
> 
> I thought thet if we are going to have the "more specialized" second
> case then I should start with this and work back to the general case
> (since the specialized case will be harder :-) to make sure I cover
> all the bases.
>     Do you have thoughts on this--how you think it should be done? I
> know that multiple locus selection and stuff is on your TODO list, so
> I figgered maybe you already had lots of great ideas for how to do it
> all :-)

For the selection of nodes for whatever purpose, I want my UI to do BOTH 2c
(rectiliner select, shift-button1 select) AND 1 (whole network select) (3
selection options, really).  But 2c brings up an interesting problem:

    Can the user EXECUTE PART of a network?  Can the user select
    and execute a processing node that needs data from a node not
    selected?

I don't think so.  IMO, the user may be able to select partial
(non-contiguous) networks for editing, etc., but s/he must select a whole
(contiguous) network for execution.  Thoughts, opinions?

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




More information about the Pipet-Devel mailing list