Re: [JDEV] Jabber DOM Proposal

[Jeremie <jer@jeremie.com>]

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

Not right, but on the other hand, there is nowhere that this happens in
the protocol.  BUT, there might be an issue if a client is using something
like that in an <ext></ext> structure and needs to parse it properly.

Basically, at this point I'd say what you have is great API-wise, and you
can leave this out... but when someone needs it a couple of extra
functions can be added to extract it.  BUT, the structs will need to store
this, similiar to how xpt handles it now.

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

Hrm... ok :)

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

Cool, sounds great, and if AVL trees are that slick I guess why not use
them!

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

Neato!

Jer