[Pipet Devel] NetInputs and NetOutputs

[Brad Chapman]

Jeff wrote:
> I'm not sure if you're asking how this can be done conceptually or
> graphically
> (in which case, I can answer the question), or how this can be 
implemented
> (in
> which case, Jarl should answer the question).

Well, I was kind of asking both, but since you both answered, all of 
my dreams have come true :-)

** The conceptual part **

Jeff wrote:
> Conceptually and graphically, it's very simple: Unconnected pipes in 
a subnet
> mean the I/O is redirected from/to the parent network.  In 
Pied/Piper, all
> "dangling" pipes are reproduced at (mapped onto) the parent node's 
icon (this
> is not implemented yet).  To "close" a pipe or create a "dead end", 
the user
> must "hide" it (also not implemented).  In Peep, the user will need 
to issue
> a
> "close" or "cap" command to do the equivalent.

Okay, this makes complete sense. Thanks! I'll work on adding support 
for this in the dl so that the xml files model this kind of behavior.

Jean-Marc wrote:
> If I understand correctly, that's exactly where NetInputs and 
NetOutputs are
> used. If you compare subnets to C functions, then NetInputs are the 
arguments
> and NetOutputs are the return value(s).

Jeff wrote:
> Brad, these are exactly the same as the inputs and outputs of a Loci
> "composite locus".  I see no difference.

Okay, it seems like we're all on the same page (for once :-), so that 
is really exciting. I think I've got what's going on and understand 
how to integrate it with what Overflow already has, so I'll move 
forward on that...

** The implementation part **

To preface this, I haven't been worry about the implementation details 
about this a whole lot, since what I'm working on doing is making the 
dl produce xml that is compliant with what Overflow current has (I 
judge this by the ability to open up the produced xml in Overflow). 
I'm presuming that this document is going to be what I'll submit to 
the bl, and then the bl/pl will be able to deal with it from there. 
Hopefully these are the same thoughts Jarl and Jean-Marc are having 
:-).

Jarl wrote:
[...snip...explanation of how GMS works...]
> The relation of 1. and 2. with your problem is this:
> 1. All output-from-the DL\UI is going into a BL-node which is 
requested
> as a input node, cq a sensor.
> 2. All nodes the UI wants to have the output from are marked too, 
this
> time as visuals. 
> So the datastreams up and down into the UI\DL\BL\PL hiarchy will be
> without much overhead. This is why we have a BL anyway :-)
> 
> I'm I making any sense? [I've the feeling my dutch thoughts arn't 
very
> well translated :)]

I think so... If I'm with you, it seems like you're saying that the 
flow of data in the bl and pl should occur independently of how weird 
the nodes are structured in the user interface and definition layer. 
So, as long as I can let you know what the connections are, you can 
run through them okay... Am I thinking along the right lines?
    If I am, then this seems to be an example of the separation 
between build time and run time that Jeff has been talking about. This 
way we can have a user interface that is easier to understand, and 
still have a rapid flow during execution. Sounds cool to me :-).

** Iterator and NetParameter part **

> Iterators must have ONE NetCondition. These Net* can be added
> by shift-clicking (or ctrl-clicking) in the node terminals. When you 
include a
> subnet in another network, it will appear as a regular node. The 
inputs of
> this node will be the NetInputs tags, the same applies to NetOutputs 
(You
> don't see
> NetConditions however, since it is used "internally" by the Iterator)

Right, I still need to add stuff for handling Iterators and haven't 
even gotten into this yet. I guess we should stick with the simple 
connection and subnet stuff for now, since that already gives us 
enough to do in the GUI. Then once we've got that settled, we should 
attack having iterators and thinking of a way to set the NetConditions 
for them.

    Thanks much for everyone's insight on this!

Brad