I haven't thought this through enough to know if feasible, but I think it'd be nice if Xerces (or any DOM Impl) had a way to "get" a thread safe implementation when needed -- like most Collections in Java do. This might take a lot of work, since I suspect there would be some "new API behavior" that would result ... such as "Concurrent modification" or "Could not make the change as requested since the node was deleted from another thread" (or some such things).
And ... I'm not volunteering :) but, I do see the need, especially in "participatory systems" such as Eclipse IDE's ... where you are never quite sure who's using your DOM. From: Joseph Kesselman/Watson/[EMAIL PROTECTED] To: [email protected] Date: 12/10/2007 04:48 PM Subject: Re: Making Xerces DOM thread-safe for read >Is the current stance a matter of principle (you don't believe the Xerces DOM should ever be made >thread-safe for read) or a practical constraint due to limited resources (you'd like the Xerces DOM to be >thread-safe, but other issues/enhancements have higher priority)? My stance: I don't believe the Xerces DOM should be made thread-safe for read at the cost of making it slower, since most folks don't need that feature and there are other (and usually better) ways to achieve the same result. That's either a principled matter of practicality, or a practical matter of principle, take your pick. ______________________________________ "... Three things see no end: A loop with exit code done wrong, A semaphore untested, And the change that comes along. ..." -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish ( http://www.ovff.org/pegasus/songs/threes-rev-11.html)
