[Pipet Devel] IRC log on XML design/Overflow inclusion in Piper

J.W. Bizzaro bizzaro at geoserve.net
Sun Jun 11 23:18:37 EDT 2000

Brad Chapman wrote:
>         jm: I've looked at your node definition and I think we agree on
> most things. I just don't think the "id" property would be necessary.
>       brad: Well, actually I use the id propery quite a bit, so I know what
> input and outputs are connected together...
>         jm: I prefer naming the inputs and outputs instead of having ids
>         jm: mostly when you have variable number of inputs/outputs
>       brad: naming <- That's fine. So if a user creates a new input or
> output, they need to create a unique name for it?
>         jm: exactly... for instance in the AND node, there's no defined
> input. You can add "ThisCondition" and "ThatCondition", ... when you use it
>       brad: names <- Okay, that sounds good to me. I'll drop the id stuff
> and start using the name as the id. I'll look into how to fix this up...

Are you guys talking about node ID's or I/O ID's?  For I/O's, I agree that a
name may be better than some randomly assigned number.  And you certainly
don't need a URI for each I/O, since it's the node (that the I/O's are
attached to) that has the URI.

But for nodes, I thought we needed an ID that contains the URI.  This way, no
2 nodes on the Internet have the same ID.

Is this no longer the plan?

>         jm: The reason I like Node is that I like to think of the program
> as a network that's made of nodes. Is the problem with Node only in the XML?
>       brad: Yeah, that's it. It is just really confusing to be referring to
> DOM nodes and Piper nodes at the same time. It even makes it hard to look
> at for me, and I'm the one coding it. Maintance will probably be a
> nightmare...

We've been through this before, and I seriously don't understand why we can't
just create our own namespace and use...



Can someone explain what is wrong?  Then in the documentation, we can still
say plain old "node".

>         jm: BTW, I had a couple coments about the screenshot. First, we'll
> need to name the inputs/outputs when there is more than one (as in vflow).
>         jm: Also, maybe we can add an "icon" tag for some nodes. For
> instance, add could be represented as a "+" sign.
>       brad: screenshot <- Yeah, I just wrote to Jeff about the exact same
> thing. The way it will work is that each little dot will have a little
> windowlet associated with it that can be opened up to display this
> information...
>         jm: I much rather see the input/output names without opening a
> dialog. Otherise, there's no way you could connect, say NetExec, without
> opening this dialog.
>       brad: dialog <- Well, it is not so much a dialog window as a little
> window that moves along with dot. This should work in the same way as the
> windows for each "node." Have you run Piper/Loci yet and seen what it looks
> like? Of course, this is all Jeff's design plans, so this is definately
> stuff you and he should hash out if you want to change it...

Besides the pipe (connector) windowlet, there is a dot at the end of each pipe
that can hold a SHORT name or number.

The problem with having names tag along with the ENDS of the pipes, is that
the ends are connected together, thus names will overlap and be obscured.

I could also position names along the center of the pipes.  I'll think about

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

More information about the Pipet-Devel mailing list