[Libxmlplusplus-general] libxml++ evolution

[Stefan S. <se...@sy...>]

Christophe de VIENNE wrote:

> Stefan, since you're actively partipating to libxml++ now, I can give you 
> access to the CVS for a while. Even if the new concepts you're bringing are 
> not yet production ready, we seems to agree on including them for future 
> releases.

sure, I think that would make things easier for us all. I also agree
with Murray that it is important to respect existing policies.
However, I don't agree that individual checkins must not generate
regressions. Sometimes changes are quite complex, and imply more than
just an implementation fix.
It is, however, crucial that the people collaborating share a common 
vision, and that the ckeckins are aligned with that. For example, the
transition to the new wrapper types I have been proposing requires some
rethinking in terms of the API. I think it's much more easy to make
the transition incrementally, accepting that the code will temporarily
contain regressions, as long as they are well known and tracked.

> One more thing : since C member instance are pointers to structure each time, 
> it would be very easy now to apply the pimpl idiom, which wouldn't be a bad 
> thing I think.

uh, well, I doubt this is a good idea in this case. DOM nodes are very
lightweight, and should remain to be. The more indirections we
introduce, the heavier we get.

Again, my vision of libxml++ is not to present an abstract XML API that
uses late (runtime) binding to map to an implementation. It is a 
specific and lightweight wrapper around libxml2. Performance must be an
issue.

Regards,
		Stefan