Hi Urs, I have to say that I'm a bit confused about this proposed patch. Maybe it's that I'm confused by what seem to be unclear semantics for your proposed "dispose" function.
Can you tell us more about how your custom DOMNode implementation works? What do you do when you receive a dispose message? Does the pointer go completely invalid, or do you really just "uncache" some large underlying data? Are you trying to optimize for the shear quantity of nodes sitting around, or for the shear quantity of data sitting behind each of these nodes? Is the semantic that you've got a large amount of data backing up the node, and that you want to release that data rather than the node itself? What about something like a "prepare/unprepare" or "cache/uncache" semantic on the node? This would keep the node pointer valid, but could give a hint to the node that it could release data that wasn't likely to be used again right away. Your patch to DOMWriter would call "unprepare" or "uncache" as it finished with nodes. Internally your node would need to call "prepare" or "cache" if access to node data were requested while in an unprepared or uncached state. As it sits, I'm uncomfortable with the patch. One thing that bugs me is that it seems to assume that DOMWriter is a dead-end for DOM nodes. It might be in your case, but that certainly isn't so in all cases. Comments from others? Any clarification of intent? James. On 2/11/03 3:33 PM, "Urs Muff" <[EMAIL PROTECTED]> wrote: > Hi, > > The current implementation of Xerces is assuming that the complete document > is in memory at any given time. This is a gross oversimplification and does > not allow for other implementations to do otherwise. The main problem is > that pointers to nodes are returned and there is no way of knowing when the > caller is done using that pointer. > > We have such an implementation ourselves (of course otherwise I would not be > concerned with that), and we provided a patch that introduces the concept of > node pointer ownership. We are more than welcome to get some feedback from > the Xerces community about this, since I know from seeing other discussions > that others have similar issues. > > All that is required is the following: call node->dispose() when you are > done using that pointer. Of course we could use something like smart > pointers, but I would say that would go against other principals I have > observed on this project. > > Anyway, I would greatly appreciate any comment or consideration of checking > in this simple change [that is hopefully are start for more]. > > - URS C. MUFF > SYSTEMS ARCHITECT - RESEARCH LAB > [EMAIL PROTECTED] > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >> Sent: Monday, February 10, 2003 11:13 PM >> To: [EMAIL PROTECTED] >> Subject: DO NOT REPLY [Bug 16954] - There should be a way to release child >> nodes, once we done with it.(Patch Available) >> >> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG >> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT >> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16954>. >> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND >> INSERTED IN THE BUG DATABASE. >> >> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16954 >> >> There should be a way to release child nodes, once we done with it.(Patch >> Available) >> >> >> >> >> >> ------- Additional Comments From [EMAIL PROTECTED] 2003-02-11 06:13 ----- >> -- >> Created an attachment (id=4807) >> DOMNode.hpp contains empty function dispose(). >> >> --------------------------------------------------------------------- >> 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]
