[phobos] [destructionator at gmail.com: Re: Fwd: [Issue 4025] New: Making network with the std.stdio.File interface]

[Adam D. Ruppe]

Aaah, I replied to the wrong address too! Sorry about that.


----- Forwarded message from "Adam D. Ruppe" <destructionator at gmail.com> -----

Date: Thu, 8 Apr 2010 18:46:00 -0400
From: "Adam D. Ruppe" <destructionator at gmail.com>
To: Andrei Alexandrescu <andrei at erdani.com>
Subject: Re: [phobos] Fwd: [Issue 4025] New: Making network with the std.stdio.File interface
In-Reply-To: <4BBE3CC1.3020903 at erdani.com>
User-Agent: Mutt/1.4.2.1i

On Thu, Apr 08, 2010 at 03:29:53PM -0500, Andrei Alexandrescu wrote:
> I was about to write that. We'd be forcing client code to be templated. 
> This is a hindrance that would need substantial benefit to justify it.

Yeah.

> ranges such as byPacket (variable-length packets returned as they come 
> off the wire)

Aye, that can be useful. Something building up on that which might be nice
too is a buffering byPacket like thing, where you can peek at the front, and
only pop off a portion of it. Let's say you have a protocol that gives a length
then the data, and you want to handle the data a full block at once.

A raw byPacket doesn't solve this by itself. if byPacket.front.length < needed,
you want to get more data, but not consume what you have; you'd like to come
back to it until the length is big enough for you.

Moreover, you might want to consume just a portion of the packet, and save the
rest for later.


In my fancier network lib, you can do this:

more:
auto a = readBuffer();
if(a.length < whatYouNeed)
    return; // this function will be called again when the next packet comes in
if(a.length >= whatYouNeed) {
    process(a[0..whatYouNeed]);
    advanceBuffer(whatYouNeed); // the next readBuffer() returns a[whatYouNeed..$]
    goto more; // start over on the leftover data
}


The functions here aren't exactly a range, but I think could be adapted to them:

read() => front()
return => getMore() // an extension. does internalBuffer ~= next packet
advanceBuffer(size) => popFront(size = all); // the size param is an extension


It looks workable and I think it would be useful.


Also, I think a byByte would be useful too, though unrelated to this specific
case.

> and byWhateverAbstractionIsNeededByZip.

What if byWhateverAbstractionIsNeededByZip is exactly what File does now? I
don't know if it will be, but if it is, wouldn't it make sense to just take File?

Then, if you want it to be able to read from memory or an input range in general,
the way I'd do it is rig up File to use the memory as its source instead of an
actual file.

> In order to ensure refcounting and timely closing, File needs to be an 
> object. It could use the pimpl idiom inside in conjunction with a class 
> hierarchy.

Aye, I think it'll work out that way.

----- End forwarded message -----

-- 
Adam D. Ruppe
http://arsdnet.net