[JDEV] Jabber DOM Proposal

[Dave Smith]

>I'm curious about this, why wouldn't you just null terminate the string
>and avoid the getTagDatumSz method?  Also, no biggie, but in XML worlds

This will change... :) Still working it out in my head...The way the
interface is setup right now, it's not gonna correctly parse certain things
like:

<tag>data1<b>databold</b>data2</tag>

would wind up being..

Tag(tag, Children(b), Datum(data1data2))

which obviously isn't right... :)

>the strings are usually called cdata... would it be more
>consistent/understandable to refer to them the same way?

Okay, that would be good.

>Are we missing?:
>      1.1) Name : String
>*g*

Actually, no. The Name is stored in the NodeList. :) It's more efficient
this way. Remember, a Node is *never* (I'm pretty sure :)) stored without a
NodeList.

>> 3.) AttribTree = a balanced binary tree (AVL, probably) contains Attribs
>> keyed by Attrib.Name
>
>I highly doubt we need this... we only have a couple of attributes at most
>on any tag, doing this extra work here would be a shame :)
>

Well, we get a lot of benefits from using AVL trees for this stuff. That
getTag() method you liked so much, is dependent on the DOM having the data
already organized by name. Memory wise, an AVL tree is the same size as a
linked list, and insertion time is minimally slower than a standard linked
list insertion on a small list. I'm still trying to decide if that's the way
to go, though. :) Probably what I'll do initially is implement a linked list
and set it up so I can easily plug-in a more efficient data structure
later -- after we've determined it's really needed. :)

>I do like it(quite a bit in fact), and it would make a client
>development(and internal stuff)  much easier to understand :)

Thanks. That's my goal. :)

>So when are you going to be checking it in?  Hehe :)

Soon. :)

D.