Hi Khalad, Sorry, I didn't have the name "quite" right ;) And since the bug doesn't have a patch attached to it yet, it's a little hard to see... Look in the DOMWriter code for the use of DOMNodeSPtr, which is the smart node pointer for DOMNodes.
-jdb On 4/4/03 11:25 AM, "Khaled Noaman" <[EMAIL PROTECTED]> wrote: > 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] > > -- /********************************** James D. Berry mailto:[EMAIL PROTECTED] vox:503.265.1213 fax:503.222.3020 **********************************/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
