At 04:42 PM 9/26/2003 -0400, David Bau wrote:

(b) Dealing with very large instances (2) also seems to leads to "lazy
object" created on demand.  For example, if the bulk of an 20GB instance is
stored on disk, yet an app can hold on to an object that represents a node,
then certainly not all nodes can be in memory at once.  They're created on
demand.

I'm not sure I agree that large payloads do necessarily lead us to lazy object creation.  In many (most?) cases, large payloads are large because they contain big chunks of base64 data, and those can be dealt with out-of-band.

And in the case where someone really does have to bite off 20GB of structured XML data at once, I have to wonder if they aren't better served by writing directly to an API like 173.


(d) The upshot: it seems like
- we need to synchronize at a low level to satisfy (4) at the same time as
allocate-on-demand
- to satisfy (3) - i.e., no synchronization cost, perhaps we should have a
global option per instance to turn off synchronization; users can use this
option if they are synchronizing themselves in a savvy mulithreaded app, or
if they are truly single-threaded.

That last bullet is a bit clumsy.  But I don't see anything better....

Agreed.  Maybe we could consider having separate synchronized and unsynchronized impls.  This would spare us the overhead of repeatedly checking a flag at runtime and might help keep the implementation more clean.  It obviously would result in more code, though, and at least a little redundancy.

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.

-p