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]
