That's exactly what we proposed: the possibility to add reference counting, but not enforcing it (not built in --> empty implementation by default). Which will have no performance impact at all, but adds the possibility to add reference counting at least for other implementations. And since Xerces is the official C++ binding, you have to consider that other implementation have to base themselves on the given interface.
- URS C. MUFF SYSTEMS ARCHITECT - RESEARCH LAB > -----Original Message----- > From: Bagepalli, Kiran [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 03, 2003 12:52 PM > To: '[EMAIL PROTECTED]' > Subject: RE: Adding RefCount support to DOMNode (was Next release) > > I certainly agree that reference counting should not be built in nor > should > custom memory handling. > Atleast the model should be open enough for people to add the cost of > reference counting if they please but should not be built in. Similarly we > should be able to manage the memory more effectively like spooling to disk > in any custom implementation. > The issue is the xerces implementation is not open enough on this front. > Kiran > > -----Original Message----- > From: Khaled Noaman [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 03, 2003 11:43 AM > To: [EMAIL PROTECTED] > Subject: Re: Adding RefCount support to DOMNode (was Next release) > > > I have not looked at the proposed changes. The question here is what do > people want. We had a version of DOM that used reference counting [1] > which is currently deprecated. People were complaining about how the > the DOM was very slow. The new DOM design was introduced with > performance in mind, and I think that we should keep it that way. DOM is > memory intensive by nature and I am not for adding more weight to the > existing DOM that makes it slower. > > Just my 2 cents worth... > Khaled > > [1] http://xml.apache.org/xerces-c/program-deprecateddom.html > > "Bagepalli, Kiran" wrote: > > > For the question at hand: It turns out that it might actually be useful > > >> to > > >> have a 2.3 release come out reasonably soon (early-mid May) because > some > > >> fairly important features should be in by then (most importantly, a > > scheme > > >> to enable users to have the parser get memory from their own heap > rather > > >> than from the system). Since this should make us substantially more > > >> robust > > >> in environments which have this capability, it might be good to have > a > > >> stable release for people to use sooner rather than later. > > > > <Kiran> Is this happening in 2.3. This will be a big boost to DOM which > is > a > > memory hog. This would enable > > users to spool DOM content to disk and not be limited by system memory. > > Kiran > > > > -----Original Message----- > > From: James Berry [mailto:[EMAIL PROTECTED] > > Sent: Thursday, April 03, 2003 10:14 AM > > To: Xerces C Dev > > Cc: Urs Muff; 'Neil Graham' > > Subject: Re: Adding RefCount support to DOMNode (was Next release) > > > > I'd like to solicit comment from other committers and stakeholders about > > this proposed patch. If people agree, I'm happy to commit it. > > > > The basic question is: > > > > - Is it proper/okay to add several additional "experimental" > interfaces > > to the DOMNode class that will enable use of reference counting in > derived > > or alternate DOM implementations that want to work with Xerces? Such > > additional interfaces can be marked experimental, and will have no > impact > on > > Xerces mainline peformance. > > > > The benefit of this is: > > > > - Groups, such as Quark, can use alternate or derived DOM classes in > > conjunction with Xerces. In the absence of this change, they are unable > to > > do so. > > > > I went over several interfaces with Urs to try to make this as broadly > > applicable as possible without affecting Xerces out of the box. But the > > question still remains: is it right to add such experimental interfaces > to > > the base Xerces DOMNode? Personally, I think it adds value in terms of > > supporting additional DOM flavors... > > > > Comments? Consensus? > > > > James. > > > > On 4/3/03 9:06 AM, "Urs Muff" <[EMAIL PROTECTED]> wrote: > > > > > Could you please look into the feature (including solution) proposed > in > > bug > > > #17945? We would really appreciate, if we at least had an answer if > it > > ever > > > will be considered to be included, and if yes, what the timeframe > would > > be. > > > > > > The feature allows custom implementation of DOMNode interface to > enable > > > reference counting over nodes (and thus their early disposal). > > > > > > We worked closely with James Berry on that solution, and we hope that > it > > has > > > a low impact and will be accepted. > > > > > > Kindest regards, > > > > > > - URS C. MUFF > > > SYSTEMS ARCHITECT - RESEARCH LAB > > > [EMAIL PROTECTED] - X6360 > > > +1 (303) 894 3360 > > > > > > > > >> -----Original Message----- > > >> From: Neil Graham [mailto:[EMAIL PROTECTED] > > >> Sent: Thursday, April 03, 2003 9:57 AM > > >> To: [EMAIL PROTECTED] > > >> Subject: Re: Next release > > >> > > >> Hi David, Gareth and all, > > >> > > >> One of the things I'm hoping to do in the next week or so is to share > a > > >> list of the work items that the folks from IBM are planning to focus > on > > in > > >> the next while, including when we thought it might be nice to have a > > >> release. This way, I'm hoping other folks (committers and not) can > step > > >> forward, volunteer for things, and we can put together a decent plan. > > >> That > > >> way, we'll all have a much firmer idea of what the next release will > > >> entail > > >> and when it will come out. > > >> > > >> For the question at hand: It turns out that it might actually be > useful > > >> to > > >> have a 2.3 release come out reasonably soon (early-mid May) because > some > > >> fairly important features should be in by then (most importantly, a > > scheme > > >> to enable users to have the parser get memory from their own heap > rather > > >> than from the system). Since this should make us substantially more > > >> robust > > >> in environments which have this capability, it might be good to have > a > > >> stable release for people to use sooner rather than later. > > >> > > >> Anyway, that's a preview of some of the things we're looking into > over > > >> here; more details (and lots of opportunity for discussion!) to > follow > > >> soonish. > > >> > > >> Cheers! > > >> Neil > > >> Neil Graham > > >> XML Parser Development > > >> IBM Toronto Lab > > >> Phone: 905-413-3519, T/L 969-3519 > > >> E-mail: [EMAIL PROTECTED] > > >> > > >> > > >> > > >> > > >> |---------+----------------------------> > > >> | | David Schulze | > > >> | | <[EMAIL PROTECTED]| > > >> | | om> | > > >> | | | > > >> | | 04/03/2003 10:10 | > > >> | | AM | > > >> | | Please respond to| > > >> | | xerces-c-dev | > > >> | | | > > >> |---------+----------------------------> > > >>> > ----------------------------------------------------------------------- > > >> --------------------------------------------------------------------- > -| > > >> | > > >> | > > >> | To: "'[EMAIL PROTECTED]'" <xerces-c- > > >> [EMAIL PROTECTED]> > > >> | > > >> | cc: > > >> | > > >> | Subject: Next release > > >> | > > >> | > > >> | > > >> | > > >> | > > >>> > ----------------------------------------------------------------------- > > >> --------------------------------------------------------------------- > -| > > >> > > >> > > >> > > >> Anyone know a more solid date than "Fall 2003" for the next release > of > > >> Xerces? It would be version 2.3.0 > > >> I'm planning on updating our code base from 1.7.0, but if 2.3.0 is > coming > > >> in > > >> a few weeks I'll wait for that instead of going to 2.2.0. > > >> > > >> Thanks > > >> David Schulze > > >> DeLorme Mapping > > >> Yarmouth, ME, USA > > >> > > >> --------------------------------------------------------------------- > > >> 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] > > > --------------------------------------------------------------------- > 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]
