Re: API proposal for charset code conversion at I/O
- From: Johannes Stezenbach <js convergence de>
- To: gtk-devel-list gtk org
- Subject: Re: API proposal for charset code conversion at I/O
- Date: Thu, 15 Mar 2001 15:48:33 +0100
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]