[phobos] Improvement of stream

[SHOO]

I think that there are two problems about I/O operation.
- Location of buffering layers.
- Direction of seeking.

Other than these two problems, it is settled from requirements naturally.
Requirements are:
- Being easy to expand Handle.
   For File, Socket, Pipe, Memory, VirtualFile, USB, Bluetooth,
   SerialPort, and so on. Handle should be the interface that can
   support them by minimum work. This means that Handle cannot have
   optional functions such as byLine as required items.
- The handling should be simple for a user.
   This is equal to supporting Ranges. General-purpose functions or
   classes to generate Range are necessary to be able to treat Handle
   easily.

It is necessary for the concept to be divided in two at least to realize 
them. (Handles and Ranges) Or more(+ Port or Stream).
The opening difficult item appears when I think about this.

(2010/09/09 2:29), SHOO wrote:
> Because it was gathered up about a past article by an argument about
> Stream of the Japanese community, I introduce it.
>
> This remark translated the summary of the remark of @s50 into English.
> ( Thanks s50! ( https://twitter.com/s50 ),
> See also
> http://dusers.dip.jp/modules/forum/index.php?topic_id=75#post_id291 in
> Japanese article.)
>
> The past arguments about the input/output are as follows:
>
>
> *
> http://lists.puremagic.com/pipermail/digitalmars-d/2008-October/043320.html
> This remark shows a claim that Andrei abandons std.stream for the first
> time.
> At this stage, it is not planning to yet become ripe.
>
> *
> http://lists.puremagic.com/pipermail/digitalmars-d/2009-January/048184.html
> Andrei shows a thought to abolish std.stream again here.
>
> *
> http://lists.puremagic.com/pipermail/digitalmars-d/2009-February/049385.html
> Andrei awfully criticized std.stream.
> He seem to have thought about the input/output that used Range in this time.
>
>
> *** Process to reach getNext ***
> The central figures are Andrei and Steven.
> Andrei has a personal view in Range for I/O.
> Steven is skeptical about Range, but agrees that developing of new
> input/output.
>
> * http://lists.puremagic.com/pipermail/digitalmars-d/2009-May/056773.html
> The first opinion about popNext is shown.
>
> * http://lists.puremagic.com/pipermail/digitalmars-d/2009-May/056859.html
> It is the topic that Steve strongly recommends popNext.
>
> * http://lists.puremagic.com/pipermail/digitalmars-d/2009-July/060404.html
> popNext to getNext.
> Andrei argued that "the simplest and most natural interface for a pure
> input stream has only one function getNext which at the same time gets
> the element and bumps the stream."
>
> * http://lists.puremagic.com/pipermail/digitalmars-d/2010-March/073856.html
> Again.
> Related: [Issue 4025] New: Making network with the std.stdio.File interface
>
> * http://lists.puremagic.com/pipermail/phobos/2010-March/000213.html
> Adam's approach to std.file.File for socket.
> The focus of this topic is reading of the variable-length data packet.
>
> * http://lists.puremagic.com/pipermail/digitalmars-d/2010-July/079011.html
> Andrei's opinion about getNext is shown here.
>
>
>
> *** Ranges and Handles ***
> Recent Andrei seems to think that Range(high level interface) and
> Handle(primitive interface) should perform input/output.
> (Just for the record, I agree this opinion.)
>
> * http://lists.puremagic.com/pipermail/digitalmars-d/2009-May/056942.html
> At first, His opinion says Ranges handle I/O instead of Streams.
>
> * http://lists.puremagic.com/pipermail/phobos/2010-March/000106.html
> He seems to think that Range should be offered by Handle recently.
>
> * http://lists.puremagic.com/pipermail/phobos/2010-April/000272.html
> Let's not forget that File isn't a range. Let's call it a "stream handle"
> (I push *Steam*. Speaking of Range, it is Microwave, Oven and
> Overheating-Steam! :-) )
>
> * http://lists.puremagic.com/pipermail/digitalmars-d/2010-June/078675.html
> "It's best to have a handle/ranges architecture in which the handle
> (e.g. File) is responsible for opening, closing, and managing the
> connection, and several ranges are responsible for fetching data in
> various ways (by character, by chunk, by line etc.)"