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

Brad Chapman chapmanb at arches.uga.edu
Sun Jun 11 23:49:21 EDT 2000


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

We were talking about node IDs. And, yup, I think names are better, as 
Jean-Marc suggested. I'll switch stuff over to using this and phase 
out ids. And nope, we don't need anything fancy like URIs for inputs.

> 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?

That's true, but I haven't really worried about it too much since we 
were concentrating on local communication right now. But I guess the 
way I was thinking about doing it was just by prefixing an id with the 
URI or whatever, the way that namespaces work right now in python.

So now we've got:

('random_id')

and for remote nodes we'd have:

('some kind of URI', 'remote_id')

> We've been through this before, and I seriously don't understand why 
we can't
> just create our own namespace and use...
> 
>    piper_node
> 
> ???
> 
> Can someone explain what is wrong?  Then in the documentation, we 
can still
> say plain old "node".

Okay, since I'm the only one that is always complaining about this and 
fighting against the use of node I'll try to explain again.
    It doesn't have anything to do with the fact that our use of node 
will "clash" with the use of node in DOM and cause variable/namespace 
problems. Prefixing our piper nodes (let's say with Pnode for right 
now), would solve this. The problem I think is that it is *really* 
confusing to me in the code to be dealing with both DOM nodes and 
Piper nodes at the same time. So in DOM code I would be doing things 
like:

dom_iterator = dom_tree.createNodeIterator(dom_tree, 
		  NodeFilter.SHOW_ELEMENT, None, 0)
		  
cur_node = dom_iterator.nextNode()

So dealing with DOM nodes and calling functions like nextNode.
    Then I would be working in Piper code and doing things like:

a_container_Pnode.add_node(some_Pnode)
a_list_of_Pnodes = a_container_Pnode.get_children_nodes()

I just think it not always very clear which functions are dealing with 
dom nodes and which are dealing with Piper nodes. 
    So, I mean, maybe I'm stupid that I have a difficult time dealing 
with two different "node" systems at the same time. But I just think 
this will make my code confusing for me, and I'm the one writing it. I 
can't really imagine how it will be for other people looking at it. 
This confusion is also doubled by the fact that the dl deals with 
corba "nodes" connecting to the UI and corba "nodes" to the bl, and 
ugh, it makes my head feel about ready to explode thinking about it. I 
am really for a term that describes Piper "things" and it always makes 
complete sense that it is a function manipulating a piper "thing" and 
not a function manipulating a dom node. Does this make any sense at 
all? 
    Of course, it is all up to the powers of voting now, but I don't 
think I am being a complete space cadet in having some problems with 
node :-).

Brad






More information about the Pipet-Devel mailing list