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]