Re: [JDEV] Client Lib & Associated Thoughts (And Many Capital Letters)

[dsmith@ai.uwf.edu]

> Firstly, that's an excellent description of the terminology, wanna help
> write developer docs?  *grin*

I wouldn't mind at all. Gimme some comments and I'll give you some
docs. :)

> This is mostly my fault for lack-of-comments at this point, but what you
> describe is almost exactly what the xpt structure is in the client lib.
> The only big difference is that it uses jpairs(simple linked lists) for
> the attributes and is C based with supporting functions instead of a C++
> class.

That's cool. Makes a little more sense now...
 
> problem, the W3C has blessed the DOM as the "standard" way to express
> parsed XML via an API.  I'd love to start working on a simple C based DOM

Doh! I thought I had come up with a awesome solution to the world's
problems XML...Oh well. :) I've skimmed over the DOM this morning
(while i shoulda been studying for finals) and was pretty impressed. If
the Jabber project is *really* going to take advantage of XML, it seems
like we oughta go ahead and implement the fully DOM internally. It's a
lot of extra work, initally, but it would really simplify the final
architecture and implementation of new transports, modules, etc...

> I haven't done any c++, but everything I know about it makes me want to :)
> I'm a very object-based thinker, so everything I've been doing in C is
> just about object oriented as C gets.

Da, I noticed that in the code. Kudos to you and the others. :) It
would probably be good to continue this approach. 

> The problem is that I really believe that the core code(server and libs)
> should be entirely pure cross platform C.  I've seen all kinds of

This really isn't a big problem, either. With good code organization
and a pseudo-object oriented approach it shouldn't be all that hard to
share the advantages of both. And when we want to provide C++ access to
the DOM, parser and such, writing a set of c++ wrappers will be trivial.
 
> Most importantly, if your preference is C++, simply implement the protocol
> and your set, no need to utilize anything else if you are capable of going
> it your own.  There's probably lots better ways to do things in pure C++
> and there's no reason we can't distribute that as an option :)

True, I guess. However, this kinda defeats the reason of having a
"common" library. :) 

So, I concur with you. Let's write a DOM. :) I found a C++
implementation on another project (www.berlin-consortium.org) and we
can probably use that as an example...

D.