The current underlying implementation is ignoring it even if it is turned on. It's the custom DOM implementation, which makes use of the provided information.
- URS C. MUFF SYSTEMS ARCHITECT - RESEARCH LAB > -----Original Message----- > From: Khaled Noaman [mailto:[EMAIL PROTECTED] > Sent: Friday, April 04, 2003 1:10 PM > To: [EMAIL PROTECTED] > Subject: Re: Adding RefCount support to DOMNode (was Next release) > > Hi Urs, > > I just want to be sure about something. Is the intended change to be > used with user's specific implementation of DOM, or is it to be used > with the current underlying implementation? > > Khaled > > Urs Muff wrote: > > > Hi Khaled, > > > > That's exactly the point: no impact change. DOMNodePtr is defined in > > DOMNode.h, and if you have ref counting on, it will be a ref counted > > pointer, and if ref counting is off, it's just a normal pointer. Once > > changed the DOMWriterImpl will never have to change again, since the ref > > counting decision/implementation got abstracted away into DOMNodePtr. > > > > This allows an implementer of a DOMNode to know when the client releases > a > > node, and can if he pleases so release related memory if no one is > accessing > > it anymore. This results in a huge advantage, for instance if somebody > is > > just walking a complete document (like the DOMWriter is doing), at any > given > > time one current node including all his parent nodes have to be in > memory, > > any prior visited nodes can be freed, since no one else is accessing it. > > All future nodes are not allocated yet, and will be allocated as soon as > > someone stumbles across one (with getFirstChild(), getNextSibbling(), or > > similar walking functions). I think many users would like such > benefits, > > and allowing an implementer to add this functionality with no impact to > > others you don't use/like it is the entire goal of this exercise. Also, > > adding it to the source pool will standardize this pattern and anyone > else > > how has similar implementation requirements can reuse the interface > > provided. Note that using the interface is completely vulnerary, even > with > > the ref counting turned on. > > > > Please fill free to ask me any more detailed questions or concerns > regarding > > this change, I'm more than willing to answer them. We already have > being > > trying to get that in for month now, and I would really appreciate, if > we > > could resolve it before the next release. > > > > Kindest regards, > > > > - URS C. MUFF > > SYSTEMS ARCHITECT - RESEARCH LAB > > > > > -----Original Message----- > > > From: Khaled Noaman [mailto:[EMAIL PROTECTED] > > > Sent: Friday, April 04, 2003 12:25 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: Adding RefCount support to DOMNode (was Next release) > > > > > > 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] > > > > --------------------------------------------------------------------- > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
