[gdome]A(bstract) DOM

[Luca Padovani <padovani scl csd uwo ca>]

Dear Gdome2 users,
(and Tobias in particular)

I've been studying at a C++ wrapper for Gdome2 for a few days, looking
also at Tobias' work. The library I'd really like to use is something
with the following characteristics:

1) it should provide a set of abstract DOM classes, basically a
   mere C++ hierarchy of interfaces (= classes with pure virtual
   methods only) following DOM IDLs

1bis) such abstract classes should be carefully designed so that
   the user is "forced" to use them the right way. For
   example, I'd like to have all classes except DOMImplementation
   to have protected constructors, so that an object of that class
   can be only constructed via the DOM interface, and not by accident
   with the new operator.
   Similarly, having a protected destructor prevents users to invoke
   delete on classes, thus enforcing the use of ref/unref mechanism
   (but see point 4))

2) it should provide a DOM compliant class for string management
   (that is, where strings are really encoded in UTF16)
 
3) it should be possible to "instantiate" the abstract library to
   a variety of different implementation. For example, we should be
   able to instantiate abstract classes at point 1) with suitable
   implementations relying on the Gdome2 engine. But it should be
   also possible to do the same with a different DOM implementation,
   eventually something which is completely native C++ and just
   relies on some SAX2 implementation (which libxml2/3 will
   hopefully support one day). The final applications should know
   very little (or nothing) about what's behind this DOM.

4) provide a layer of smart pointers which is separate from the
   hierarchy at point 1) (much like xerces). This gives the user
   the freedom to choose at which level he/she wants to access
   the library (it is well known that smart pointers often introduce
   overhead). Furthermore, smart pointer classes can
   be created regardless the actual implementation at point 3).

5) the possibility to instantiate the library at runtime. I mean,
   I want to be able to decide at runtime what underlying implementation
   I want to use. Here is Gdome2, there is something else. This
   reduces the dependencies of the binary distribution package, provided
   that it's split into several different libraries, one for each
   possible implementation. It's also a way for the library to adapt
   more flexibly to the characteristics of the system. 

I believe Tobias' code can be very helpful for this, and even though
I know nothing about Ruby I'm pretty sure it can be adapted so to
achieve most of the points above (also, I'd like to have one .hh file
for each class, not a huge .hh file with everything, same for the
implementations).

As usual, further discussions, comments, suggestions are more than
welcome. I can provide (for free) code, time (limited) and enthusiasm.
I'd really like to make this C++ library comfortable, so that
more and more users will be using it (aren't you tired of C? ;-) )

Best regards,

	luca

P.S. the top would aldo be an implementation of the library for
GCJ.