[Pipet Devel] executing a network script

[Brad Chapman]

Jeff wrote:
> 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?

It sounds good, except lets say I have xml like:

<piper_node>
    stuff about the node
</piper_node>

If I stick this into dom, I have been referring to things basically as 
their tag with _node appended, so this would translate into a variable 
called 'piper_node_node' (where it had previously been 'locus_node'), 
which is really ugly :-)

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

I think we should, but it is not clear to me how the BL and PL (gms 
and overflow) will work together exactly, so I don't know how to name 
them yet...

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

Okay, all of the options :-)
 
Jeff wrote:
>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?

Jean-Marc wrote:
> I think that if we want, at some point, to allow executing part of a 
network,
> this can be done by creating a network from the selected nodes, and 
executing
> this network.

    I agree with both of you that executing a partial network will be 
really tricky, especially at the beginning. My thought was to try and 
have the dl "check" the work-flow-diagram/network and look for things 
like needing input that is not in the diagram, and then returning an 
error to the front before submitting to the bl. This will probably be 
some work and not be perfect at the beginning, but we can try to work 
through it and see what kind of errors we get from different weird 
work flow diagrams.
    The bigger issue here is that I think Jeff and Jean-Marc have two 
different ideas about what a "network" is. It seems like (from my 
little experience using Overflow before it seg-faults on me :-) in 
Overflow a network is always the entire workspace (in Loci terms). It 
kind of models it like this since a network is like the main function 
in a C program and the nodes are like functions it calls (am I right 
on this?). While in Loci it seems like Jeff was thinking that not 
every node inside of workspaces would necessarily be part of the 
network (only those that were selected). The Loci way seems more 
flexible, but is definately more of a pain. 
    What Jean-Marc said above seems to be what I was thinking about 
doing in the dl, is to turn only the submitted (selected) nodes into 
the network that is submitted to the bl. I'm not sure if this helps 
take care of the issue of workspace=network versus workspace != 
network to everyone's satisfaction?

    Along these lines, I was also curious. What are the plans for 
trying to integrate the Overflow GUI with the Loci GUI? Will the 
Overflow GUI be a "composite locus" that can be loaded up? Can we make 
C Gtk/Gnome talk with python Gtk/Gnome (ie. transfer the control of 
the gui to the Overflow GUI when a user clicks inside the composite 
locus holding the Overflow GUI)? I was just curious how this was going 
to work.

Brad