[Pipet Devel] Thoughts on Network/Composite Inputs and Outputs

J.W. Bizzaro jeff at bioinformatics.org
Thu Jul 27 07:06:37 EDT 2000

Brad Chapman wrote:
> Whenever a new node is added inside of a Composite Locus (or Network,
> for Overflow) all of the unconnected inputs and outputs are
> "inherited" by the parent Composite Locus, so that they can
> potentially be connected with other loci in the same level as the
> parent Composite Locus. This is the situation of things right now if
> you grab the latest Piper from CVS.

The idea that I had was that the I/O's (links) you DIDN'T want mapped to the
parent could be explicitly HIDDEN.  This is the opposite of what you propose
below (where you bring up some good points), because everything gets mapped by
default.  I just wanted to mention this, because it is not as though the user
could not (when implemented) "unmap" a link.

> 1. The composite loci end up with a ton of NetInputs and NetOutputs
> (to use Overflow terminology), and I think this will make it really
> tough to see what NetInputs and NetOutputs go with which internal
> Loci, even when viewing the names of inputs and outputs is implimented.

When building a large subnet, I can see how you might end up with dozens of
links mapped to the parent, and that could get ugly.

> 2. Having been thinking more about it, it seems like this behavior
> isn't really what I would want as a default. It seems like that 90% of
> the time when I add a new locus I'm planning on connecting it to other
> loci in the same network. So, based on this we are doing a lot of
> extra work with adding and removing inputs for maybe 10% of the cases
> when an input or output will feed to the outside of a network. In
> addition, this behavior may be confusing to a user, who wouldn't
> expect to see inputs appearing and dissappearing randomly.

Good point.

> 3. The situation gets messed up when you have a composite inside of
> another composite. Then if you add a new locus to the inner composite,
> the new inputs are inherited into that composite, and then since they
> aren't connected there, are then inherited again into the outer
> composite.

That's an excellent point and something I didn't consider.

> 4. All of the above stuff makes this kind of a pain to maintain, and
> also slows things down quite a bit.

I can see how slow it is.  And we do want to keep communication to a minimum
when working through an object broker can make things this slow.

> What I'd like to propose is that we change this behavior to be similar
> to that used in Overflow. A user would have to click on an input or
> output  and then specifically request that it be inherited to the
> parent locus.

Great.  I say we go ahead and do that, and we can nix the option to hide a
link (explicitly unmapping a link).  I think what we can do is place a "P" in
the dot, indicating that communication is from/to Parent.  In addition, the
dot can turn green when its mapped counterpart on the parent is also green. 
Can the DL send that information (whether the link on the parent is connected
or not) to all the child nodes?

> The user would then also supply a name for it (like in
> Overflow) and then this name would help associate the NetInput with
> the internal locus connector to which it is associated.

Shouldn't links have names by default?  And then the user can change it if
they want.

BTW, I'm impressed with how far you've gone toward adding Overflow features to
Pied.  You guys have to check this out!  I will be taking the job of
developing Pied over from Brad now, which will give him more time for other

J.W. Bizzaro                                           jeff at bioinformatics.org
Director, Bioinformatics.org: The Open Lab     http://bioinformatics.org/~jeff
"Let the machine do the dirty work." -- Kernighan and Ritchie

More information about the Pipet-Devel mailing list