On 9/22/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > 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
streaming use case: 3 efficient parsing of data in a InputStream 3a (example) efficient parsing of data streamed from a (blocking) socket 3b (example) efficient parsing of data streamed from a file opened with bio (blocking io eg FileInputStream) - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
