HI James, The bug has a copy of DOMWriterImpl.cpp attached to it. I have looked at the code and there is no use whatsoever of DOMNodeSPtr.
Khaled James Berry wrote: > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
