Re: API proposal for charset code conversion at I/O

[Johannes Stezenbach <js convergence de>]

Owen Taylor wrote:
> 
> My attempt was to make the minimal API changes necessary for charset
> conversion, not create a lot of new API elaboration, which, I think
> might be best done by simply replacing GIOChannel with something
> better.
...
> The API's I'm aware of in this area include, among others:
> 
>  QTextStream
>  .NET System.IO
>  Java character streams
...
> But both QIODevice and System.IO.Stream (the low level layers)
> actually have buffering in the low level layer.
> 
> It's quite possible we should have some such low-level / high-level
> distinction eventually.

I think so. All the above APIs add make a distinction between
binary and text streams, and add character set conversion to
text streams only.

All these APIs also make a distinction between an IO device
abstraction that encapsulates the OS calls and does generic
buffering, and a layer on top of it which performs the conversion
between internal and external data formats (like character set
conversion, or reading/writing ints/floats).

Unfortunately the nomenclature used in those APIs doesn't
always make that clear, e.g. M$ calls their IO device abstraction
"Stream". (Which isn't wrong, according to the definition
of "stream" on http://www.foldoc.org/).

IMHO a GIOChannel should stay a simple IO device abstraction.
It's better to put conversion stuff in a new class of its own.


Regards,
Johannes