Hi James,

I have looked at the DOMWriterImpl.cpp attached to the bug. I do not
see any reference to the nodeptr classes that you mentioned in your note
and are proposed in the solution. I would like to get a better understanding
on how the proposed changes are to be used.

Khaled

James Berry wrote:

> I've asked the Quark folks to modify the patch to incorporate some of the
> various feedback.
>
>  - Existence of the interfaces will be conditionalized with the
>    macro XML_DOMREFCOUNT_EXPERIMENTAL.
>
> Note that nodeptr classes are provided to ease the burden of deciding
> whether reference counting is used or not, and to eliminate any overhead.
> The classes internally examine the macro to determine whether to use
> addRefcount/decRefcount or simply copy the pointer. Any code that wishes to
> support the experimental interface, but not commit to it for all cases (or
> risk the burden thereof), can use these classes. That is how the adoption
> inside DOMWriter is done...this makes for a clean adoption.
>
> -jdb
>
> On 4/4/03 1:44 AM, "Alberto Massari" <[EMAIL PROTECTED]> wrote:
>
> > I agree with Gareth wrt to have a mechanism to include/exclude these two
> > new methods from the build. I'll try to summarize the reasons...
> >
> > - If the methods are in the public DOMNode interface (even if the official
> > implementation is an empty function), the client code is required to invoke
> > them properly (e.g. when storing a pointer to a DOMNode for later
> > processing; now the client code assumes that it will become invalid only
> > when the DOMDocument or the XercesDOMParser objects are deleted, but at
> > this point this is no more true). That means reviewing/rewriting code that
> > has been written against Xerces 2.0, and this is not acceptable. You could
> > object "if your application currently doesn't call addRef/releaseRef, you
> > don't need to add them"; but think about a company that produces a plugin
> > (using the Xerces DLL) being hosted in an executable that uses the same
> > version of the Xerces DLL: if they exchange DOMNode pointers, they could be
> > expecting a wrong behavior (like: the plugin will call addRef on the
> > pointer I give him, so I will call releaseRef as soon as the call completes
> > -> plugins makes booooom!)
> > - (I didn't really check the Xerces code to see if this scenario exists)
> > Every DOMNode stored inside Xerces objects should be addRef-ed, even if the
> > methods are stubs, and this means a little performance penalty also for the
> > stable/official release (it's not like calling an empty inline function,
> > it's calling a virtual table function, i.e. the function must be called
> > every time)
> >
> > So, the options I see are:
> > 1) we don't add addRef/releaseRef; if someone wants reference counted DOM,
> > use the old DOM_Node. If the memory management of DOM_Node makes it slow,
> > improve it
> > 2) we add addRef/releaseRef, but inside a #ifdef section; all the code
> > inside Xerces that stores copies of DOMNode objects, will have the proper
> > calls inside the same #ifdef (or maybe store a wrapper<DOMNode> object that
> > takes care of calling addRef/releaseRef when the proper #ifdef is used)
> > At this point we must signal that this DLL has (or has not) the two
> > methods; the only way it to generate a different DLL name, and use a
> > different namespace name. As a side effect, we are placing the plumbing for
> > the feature "Selectable Component Build (Xerces-C++ Lite)"; we could create
> > a bunch of macros that enable/disable part of the build, generating a
> > different library name.
> > Examples of selections:
> > - Include/Exclude deprecated DOM (it's more than 200K of compiled code...)
> > - Include/Exclude proprietary extensions to DOM interface
> > - Include/Exclude schema support
> > - Include/Exclude DTD support
> >
> > Just my € 0.02
> >
> > Alberto
> >
> >
> >
> > I would prefer if the addRef/releaseRef methods were inside an #ifdef
> >
> > At 09.51 04/04/2003 +0100, Gareth Reakes wrote:
> >> On Thu, 3 Apr 2003, Khaled Noaman wrote:
> >>
> >>> If I understand correctly, the new proposal has nothing to do with the
> >>> underlying DOM implementation. The proposal is to add two new
> >>> non-standard extensions to DOMNode. My concern is that we are
> >>> mixing implementation issues with standard spec compliance. The
> >>> DOMNode and its underlying DOM tree represent an interface for
> >>> the DOM spec, and the details for the implementation is left to the
> >>> users. I agree that adding those two new methods won't affect
> >>> performance, but I think that we should not add any implementation
> >>> specific methods to the DOM interface.
> >>>
> >>> Just my 2 cents worth...
> >>
> >>
> >> I normally am against adding any non standard methods into the DOM
> >> interfaces. The one area where I am not immediately against this is memory
> >> management. We already have a non standard release call to deal with the
> >> current model. If we want flexibility for users of xerces-c then it does
> >> not seem unreasonable to add additional methods. As these are non standard
> >> I would have no problem with them being in ifdefs and requiring a special
> >> build. I know this is a frequently requested feature and considering it is
> >> low impact I don't have an objection to giving it a try.
> >>
> >> as with Khaled - just my 2 pence :)
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to