From: Patrick Calahan
> In any event, though, maybe we could just defer the question of
synchronization until later?  It seems like it would be easier to just get
going on an unsynchronized impl, and than come back and see where we need to
lock it down in order to provide a threadsafe one.

I think the reason eric and I are obsessing a bit about synchronization
up-front is that during the development of v1, we left the synchronization
issue to the end and paid a significant performance penalty for it at the
very end.  (We still ended up being quite fast, but if you remove the
synchronization, it's measurably faster.)

This issue might be inherent to the problem; it is sorta looking that way.
Or it's possible that there is some way out if we plan ahead, e.g., by
altering our public API design etc (although obviously W3C DOM is
immovable), so that's why we're worrying about it early.

David


- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/