On 9/21/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: > > > > Serge Knystautas-2 wrote: > > > > Thanks for raising this project scope issue since IMHO these are the > > bigger than technical decisions. If I can restate, currently we > > support both non-streaming and streaming uses, and have a cursor API > > out of that. The project scope question at hand is if we drop support > > for non-streaming (and thus the cursor API) and just optimize for the > > streaming use case. > > > > Could anybody please be so kind and start with an explanation what > "streaming", or "non-streaming" means? I have the definite impression, that > we are talking quite different things here. In particular, I am far from > understanding why they should be mutually exclusive.
i'm not sure that they are necessarily mutally exclusive but i do believe that good support introduces complexity and leads to unnecessary debates about design some non-streaming use cases: 1 efficient parsing of nio data (primarily ByteBuffer) 1a (example) parse contents of single ByteBuffer (eg backed by byte array) without double buffering 1b (example) parse contents of a Channel (eg memory mapped file) without double buffering 2 efficient parsing of structured data 2a (example) parse MimeMessage without transfering raw data to an input stream 2b (example) parse mail message stored as fully or partially parsed records in a data source (eg database) without transfer of raw data to an input stream - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
