RE: gtk-devel-list digest, Vol 1 #556 - 1 msg



Title: RE: gtk-devel-list digest, Vol 1 #556 - 1 msg

unsubscribe.

-----Original Message-----
From: gtk-devel-list-request gnome org
[mailto:gtk-devel-list-request gnome org]
Sent: Friday, March 16, 2001 1:06 AM
To: gtk-devel-list gnome org
Subject: gtk-devel-list digest, Vol 1 #556 - 1 msg


Send gtk-devel-list mailing list submissions to
        gtk-devel-list gnome org

To subscribe or unsubscribe via the World Wide Web, visit
        http://mail.gnome.org/mailman/listinfo/gtk-devel-list
or, via email, send a message with subject or body 'help' to
        gtk-devel-list-request gnome org

You can reach the person managing the list at
        gtk-devel-list-admin gnome org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of gtk-devel-list digest..."


Today's Topics:

  1. Re: API proposal for charset code conversion at I/O (Johannes Stezenbach)

--__--__--

Message: 1
Date: Thu, 15 Mar 2001 15:48:33 +0100
From: Johannes Stezenbach <js convergence de>
Organization: convergence integrated media GmbH
To: gtk-devel-list gtk org
Subject: Re: API proposal for charset code conversion at I/O
<87y9u82pzn fsf gimp org> <ybed7bk86qp fsf fresnel labs redhat com>

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



--__--__--

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


End of gtk-devel-list Digest_______________________________________________
gtk-devel-list mailing list
gtk-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]