Re: [Libxmlplusplus-general] parametrizing libxml++ for the character /string type

[murrayc t-online de (Murray Cumming)]

On Wed, 2003-01-29 at 16:15, Stefan Seefeld wrote:
> Murray Cumming wrote:
> 
> > We must fix these memory leaks before we can think of applying the
> > patch.
> 
> well, I was under the impression that you'd put these changes into
> an 'unstable' branch.

Yes, but even in the unstable branch there's no point in applying major
stuff unless we know it's going to work completely.

Actually, _I_ started to think that we might even get this into 1.0 if
it proves itself quickly enough.

>  While I agree that it is important to track
> all changes, some things are hard to change under such constraints
> (for example a stable API). As an example, there ar methods that
> shouldn't be there. Some objects should never exist 'unbound'.
> If for example an 'Attribute object always has a parent 'Node',
> it's easy not to leak memory. However, if you want to be able to
> construct attributes freely, things are different. That's one aspect
> of the issue I was alluding to as 'specify ownership semantics'...
> 
> Please let me know how you would like to proceed.

Well the patch as it stands seems to leak C++ wrapper instances. That
needs to be fixed - I like the idea of using the new libxml2
notification stuff to that.

>  I have a long list
> of things I'd like to submit / check in, and I'd like to get forward
> as fast as possible (I'd like to use this in my own projects and at
> work).
> 
> Again, I can work out a switch of the implementation in a single atomic
> patch, but that would imply changes to the API,

What API changes are required?

>  as well as changes to
> configure (as I said, the libxml2 callbacks we'd want to use are only
> available since 2.5.1, so we have to make sure the version is recent
> enough).

No problem.

>  I tend to think that it would be easier to work on an unstable
> branch, if you don't want to compromize stability for your users. 

Let's consider creating a branch after that first patch is finished.
Maintaining 2 branches is difficult so I'd like to postpone it as much
as possible. Ideally branching happens after 1.0.0. But I don't want to
delay your work either.

> (By
> the way, what's the timeframe for the release of the stable libxml++
> version ?)

Soon? I feel we should wait a few more weeks just in case. Personally I
want it for a stable Bakery release and that won't happen for a month or
so.

> > Please keep changes in separate patches. I don't see how the addition of
> > a Document type has anything to do with the other changes.
> 
> right, keeping patches on focus for a specific purpose is important.
> Yet I tend to think that a new 'Document' type fits in here, as it is
> consistent with the other changes that directly map between libxml2 and
> libxml++ types.

If you can do it without creating that class then it isn't necessary. Is
there a libxml2 document "class"?

>  The DomParser class now has a number of members, which,
> with the new implementation would all be owned by a single Document
> object (i.e. via _private members of the impl object...).

Yes, I'd like to see this, but it seems separate (but dependent) to me.

-- 
Murray Cumming
murray usa net
www.murrayc.com