[phobos] Fwd: [Issue 4025] New: Making network with the std.stdio.File interface

[Andrei Alexandrescu]

On 03/30/2010 06:03 AM, Steve Schveighoffer wrote:
> Can you detail the reader/writer operations?  Because popNext and
> front ain't gonna cut it for streams.  Most of the time the element
> size you want is defined by the application (and not easily
> abstracted), not the range, but the range is in charge of the element
> size (via front).

I think there's no necessity that a range has a constant-size element 
type. If the element type of the range is e.g. ubyte[], then it can be 
free to transfer as much data as it wants at each popFront().

> While I believe ranges can be useful for streams, they are not the
> best interface for all applications.  For example, if I have a
> protocol that reads 2 bytes to get a length, and then reads length
> bytes from the stream, a range of those units is probably a good
> abstraction.  But I don't want to resort to C calls to create that
> abstraction -- there should be a nice D layer in between.  I should
> not have to create my own buffering solution.  I/O performance is
> more important IMO than interface when it comes to streams.  This
> does not mean big-O complexity, I'm talking about raw performance.

I think the interface you described can be easily modeled as a range of 
ubyte[]. Again, a range of ubyte[] doesn't have to return the same 
number of elements each step.

> I hope we can see a design before you commit to doing it this way.
> For example, a zip library uses a range as a source, what does the
> file range look like that satisfies the range properties and also is
> efficient?  Just seeing the API should be enough to judge.

Feel free to suggest one. I won't be able until I study the zip file format.

> And are there plans to make a good abstracted library for streams
> that custom ranges can be built upon?

Not sure I understand this.


Andrei