Streaming library

[Denis Koroskin]

On Fri, 15 Oct 2010 23:54:32 +0400, Kagamin <spam at here.lot> wrote:

> Denis Koroskin Wrote:
>
>> > I think, it's better to inherit Stream from InputStream and  
>> OutputStream.
>> > Do you even need endOfStream? From my experience, it's ok to
>> > blocked-read and determine end when 0 is read. Even if you read from
>> > network, is there a point in non-blocking read?
>> >
>>
>> Probably, I think I'll try both ways and see which one turns out to be
>> better.
>
> I should say, that implementation will be somewhat tricky, as different  
> kinds of streams handle reads beyond end in different ways. Say, reading  
> from a pipe whose write end is closed results in an error.
>
>> Either way is fine with me. But I agree yours is handy, too.
>> I was actually thinking about a plain ubyte[] read(); method:
>>
>> struct BufferedStream
>> {
>> 	ubyte[] read(); // just give me something
>> }
>
> Funny idea.
> Here we can also think about MemoryStream: when you have all the data in  
> memory, you don't need user side buffer, and can just return direct  
> slice to data as const(ubyte)[].

Yeah. I'm also investigating into reading/sending multiple buffers at once  
(aka scatter-gather I/O:  
http://www.delorie.com/gnu/docs/glibc/libc_246.html)

It most likely won't be a part of a Stream interface, because I'd like to  
support different types of buffer ranges, and that asks for a templated  
implementation:

size_t writeRange(Range)(Range buffers);

Each element of Range needs to be of type ubyte[], and no other  
requirements. Returns number of bytes written (not number of buffers,  
because data transmission might stop at a middle of buffer.