Quoting Kevin O'Neill <[EMAIL PROTECTED]>: > An iterator gives the driver developer control over the document > instantiation point.
No. Again, I keep talking about the case where I am parsing a SOAP or XML-RPC response including multiple documents. The driver developer is parsing an XML document. His task is to split the whole response into multiple smaller pieces. For the sake of performance, he must not convert the large document into an object tree and work on that. Rather he will create a SAX handler or use an XML pull parser and some simple state engine that allows to detect document boundaries. This will always stay the same. > Ahh ... but this is what you normally want to avoid. True. I *normally* want to avoid it. My proposal was to keep the iterator API as it is, but extend it with an event model that allows streaming. > I recently had the > displesure of working with a system that returned a set of files this > way. It was trivial run the client out of memory by simply calling a large > enough result set. Yes there are work arounds (otherwise we would not have > been able to deliver the system). I would assume that there was some kind of error. Streaming is important right for that case, because it avoids to store the result set in memory. My original point was that the iterator API *forces* storing the result set in memory in certain cases. (When parsing a large XML document containing the result set, for example a SOAP or XML-RPC response.) Jochen
