- 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 :)
Gareth
-- Gareth Reakes, Head of Product Development +44-1865-203192 DecisionSoft Limited http://www.decisionsoft.com XML Development and Services
--------------------------------------------------------------------- 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]
