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

[Brad Chapman]

Hey all,
	Jean-Marc and I were chatting up a few design things on IRC. Here's
the log if anyone is interested :-)

        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
        jm: Also, what's the path in: <!DOCTYPE locus SYSTEM
"../dtd/locusPlugin.dtd">
      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: <!DOCTYPE> <- That's the reference to the DTD. I'm using a
validating parser to check the xml so now we can have a DTD and do things
the proper way :-). This also helps me pick up bugs when I make dom
mistakes...
      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...
        jm: Well, I don't really like to hardcode paths (even relative ones).
      brad: path <- Well, that is actually just a placeholder for the real
path. When I copy a file into "use." I adjust this to point to the actual
place that DTDs were installed. So it is not "really" hardcoded, it is just
in place until I can put it to the right thing :-)
        jm: Can't the parser look for that file? That way, there's no need
for it in the definition.
      brad: parser <- No, we need to tell the parser where to find it. The
best solution will actually be to put the dtd on the web and then hardcode
the definition to point to it.
        jm: Then you can't use piper without an Internet connection?
      brad: Oh right, that's a problem :-<
      brad: Okay, I guess I'll have to stick with the local stuff...
        jm: I'd like to be able to move those files around like in matlab
where you can put the .m files anywhere and they'll still work.
        jm: Isn't there any way to tell the parser to take that .dtd file
for this document?
      brad: Move around <- I don't _think_ this will be too much of a
problem. When piper loads up a file, it could then convert the dtd ref to
point to the right place (since it will know it)... I need to think about
this, you are right.
      brad: parser <- Maybe! Good idea :-). I look into the code and see if
I can find anything... That would make it more flexible.
        jm: Otherwise, it's like a word document that needs to be in a
specific directory to load.
        jm: BTW, what's going to be the "official" name for Node or locus?
      brad: Right, I agree. Since I haven't touched "creating new .n" (or
.cls, what do you want?) I hadn't thought about it yet...
      brad: official name <- Do you hate "locus"? I mentioned why node is a
problem for me...
        jm: I like the .n extension (fits for both 'node' and 'network').
However, I don't really like Locus and you don't like Node... any other
idea?
      brad: Okay, we can use '.n', I'll drop '.cls' from now on...
      brad: ideas <- Not sure. That is why I've just been sticking with
locus. My creativity level is not that high :-)
        jm: There's two things here: the "internal" names and the way we'll
call it in the user manual.
      brad: Agreed, but I'd like to keep those the same, so people can look
at the code (and help hack on it :-), without it being too confusing...
        jm: My problem is that "Locus" won't tell much to most people. As
for Node, well, you know the implications better than I do.
        jm: Also, Overflow defines the Node (base) class and I'm not sure I
want to change that.
        jm: Is that a problem?
      brad: The problem is that we are kind of just referring to everything
as a "thing." To me, that is what node means :-). Maybe we should just
refer to everything as "thing." I don't know, what are some synonyms for
node? What does it mean to you?
      brad: Overflow code <- No, I don't think it is worth messing around
with old code for a dumb reason like a name change. I would never force
that on anyone. It would just be nice to be able to be consistent from now
on...
        jm: I don't know, after all, English is not my first language ;-)
      brad: Maybe there is a good French word? :-)
        jm: What about "Patente a gosse"
      brad: There you go!
        jm: The problem is that you need to be from Quebec to understand.
      brad: Actually, I wouldn't even care if we had a French word whose
meaning I didn't know, as long as it was consistent...
        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...
        jm: Maybe Atom?
      brad: Sure, atom would be fine!
        jm: or processor?
      brad: Atom is shorter :-)
        jm: or even "function" since that's what it is.
      brad: Well, that is kind of confusing too. Especially for nodes
representing programs...
        jm: I like to keep the matlab analogy, since after all is a similar
language, with an added visual part.
      brad: So matlab uses node? (I've never used it, so I'm not positive
what analogies you are drawing...)
        jm: No, matlab uses "functions". Also, if we are to replace "Node"
with something else in the UI* classes, I would help a lot to have the
classes still understand the "old XML", otherwise, the switch would be a
pain for me.
      brad: It's up to you. Mostly "node" is the most confusing in my
opinion (although it is the best :-<. We can just make an arbitrary
decision now, or we can throw it out to the list or whatever you want...
      brad: old XML <- We should do this. Once we get the "new XML" style
firm, I'll look at a way to load up old XML, or convert it to "new XML." I
kind of wanted to play with XSLT transforms anyways...
        jm: I suggest a vote. We could use the new name in the code, but
keep the "Node" tags in the .n files until piper is ready.
        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).
      brad: vote <- Sounds fine. I can send an e-mail, if you tell me the
candidates you want :-).
        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 see "Node", "Locus", "Atom", "Processor". Maybe we should
just raise hands ;-)
      brad: :-)
        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.
        jm: Or it could be in the preferences.
      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...
        jm: Take a look at the new .n for constant I sent you (I didn't
bother to change Node yet).
        jm: I haven't been able to start piper (and not much time to
investigate yet). What I'm saying is that I prefer the vflow way: inputs
are named and you popup a window for dialogs. I think it's simpler if you
have many nodes in a network. I have some programs that have 20-30.
        jm: Well, it's dinner time for me. We can continue later if you like.
      brad: new .n <- That looks good. I'll send comments on it by e-mail
if it's time to eat :-)
        jm: ttyl.
      brad: ttyl! Have a nice dinner :-)