DOMNode destructor

[Urs Muff <um...@quark.com>]

Destructor should be hidden too, since it is not allowed to delete a
DOMNode, since it is owned by the implementation.  You have to call
release() to dispose of the memory.

class CDOM_EXPORT DOMNode {
...
public:
    //
-----------------------------------------------------------------------
    //  All constructors are hidden, just the destructor is available
    //
-----------------------------------------------------------------------
    /** @name Destructor */
    //@{
    /**
     * Destructor
     *
     */
    virtual ~DOMNode() {};
...
};

There is conceptual problem with the design/architecture, that 'the
implementation owns all the nodes'.  This makes it virtually impossible to
implement a memory efficient implementation.  A DOMBuilder will walk over
the entire document.  Imagine that a certain implementation does only create
DOMNodes on the fly.  Right now there is no way of telling if a user still
holds a reference or not.  A simple releaseRef() would probably help at
least a little.  My prior implementation which was done on Xerces 1.7, where
I had my own DOMNode [to make it pure virtual] had the following concepts:
-	Any pointer returned by any DOM function is owned by the user and
has to be disposed of
-	The real implementation can be shared amongst multiple objects, and
reference counting can be used to keep track of expense memory
-	This allows that a tree walker always only has all the nodes in the
path to the root [since it is normally recursive] in memory, and all the
other nodes [including of course attributes] can be disposed as soon as they
are not used anymore.  This keeps the overhead and memory footprint to a
minimum.

I think the 'release' method is not W3C IDL defined anyway, and W3C does not
defined anything about the memory management as far as I know.  I know that
I'm a little late with that, but I just converted to 2.1 and encountering
the problem now, that everything stays in memory until somebody calls
DOMDocument::release.

- Urs C. Muff
Systems Architect   	- Research Lab
UMuff@Quark.Com