After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 106686 - GIOChannel too limited; stream API needed
GIOChannel too limited; stream API needed
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: general
unspecified
Other other
: Normal enhancement
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2003-02-21 08:27 UTC by Colin Walters
Modified: 2011-02-18 16:13 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
C src: GIOChannel emulated from GnomeVFSHandle (8.70 KB, text/plain)
2003-02-21 09:15 UTC, Jan Kratochvil
Details
C src: Detect file size of GIOChannel (2.81 KB, text/plain)
2003-02-21 09:16 UTC, Jan Kratochvil
Details
C src: r/w GIOChannel from r/o GIOChannel by nonpersistent memory buffering (15.47 KB, text/plain)
2003-02-21 09:17 UTC, Jan Kratochvil
Details

Description Colin Walters 2003-02-21 08:27:41 UTC
The current GIOChannel is fairly nice, but it has a number of limitations
which make it unsuitable for use as a general stream API for GNOME
applications.  The two big ones are the lack of integration with GnomeVFS,
and the lack of extensibility by applications.  Another (lesser but still
important problem) is the inability to "peek" at the buffer without reading
from it (very useful for parsers).

There is a proposal up here:
http://web.verbum.org/~walters/files/stream/
for a new stream API.
Comment 1 Jan Kratochvil 2003-02-21 09:15:59 UTC
Created attachment 14496 [details]
C src: GIOChannel emulated from GnomeVFSHandle
Comment 2 Jan Kratochvil 2003-02-21 09:16:56 UTC
Created attachment 14497 [details]
C src: Detect file size of GIOChannel
Comment 3 Jan Kratochvil 2003-02-21 09:17:51 UTC
Created attachment 14498 [details]
C src: r/w GIOChannel from r/o GIOChannel by nonpersistent memory buffering
Comment 4 Ryan McDougall 2004-01-15 23:45:50 UTC
Although Colin Walters paper seems to have vanished, it doesnt appear
anyone has commented on Jan Kratochvil's patches -- doing so would be
appreciated.
Comment 5 Mikhail Zabaluev 2004-02-15 00:55:30 UTC
GIOChannel patches aside, here's a proof-of-concept implementation of
a GObject-based extensible I/O system.

http://people.altlinux.ru/~mhz/software/sources/goio-0.1.0.tar.bz2

For now, it defines the base class GoioObject, featuring state and
close methods, and a set of interfaces that define features of
subclasses, namely GoioReadable, GoioWritable, and GoioFile (for
seek). The only subclass yet available, GoioUnixFile, implements
open(3)/read(3)/write(3) file access. Waiting in line to be classed
are stdio files, sockets, buffered readers/writers, iconv stream
converters. SSL/TLS stream encryption/decryption filters are also
planned, though not in the core library.

Contrary to my own expectations, the overhead for GObject machinery is
not too significant, as can be seen from the 'perftest' example
program, which reads 1023-byte chunks from /dev/zero 10M times using
both plain libc functions and GoioUnixFile. Here is one of the less 
favorable results as seen on my box (Linux 2.4.22, glibc 2.2.6, goio
compiled by gcc 3.3.3 with -O3 -march=i686):

Timing libc reads...    12.5    (user 3.26)
Timing goio reads...    14.6    (user 6.06)
Comment 6 Tim Janik 2004-02-19 16:50:54 UTC
this is a too major change to make 2.4, moved to 2.6 API.
Comment 7 Dominic Lachowicz 2004-08-13 20:33:38 UTC
fyi, there is such a library (libgsf) already being used by Gnumeric, AbiWord,
KOffice, and to some extent, OpenOffice. it may be worth checking out, and
perhaps merging our efforts. cc'ing jody and myself.
Comment 8 Jody Goldberg 2004-10-25 20:15:13 UTC
The gsf api is nice for document handling, but poorly suited to general i/o (we
make assumptions that the stream size is known in some of the stream types). 
The structured file elements are useful.  We're likely to do a gsf-2 version in
the next year to clean up some of the interface now that we've cot solid
experience with it.
Comment 9 Andreas Rottmann 2005-02-01 13:22:05 UTC
I have checked in the GOIO code in my Arch repository (see
http://yi.org/rotty/Software#gnuarch). You can browse the code via
http://rotty-ipv4.yi.org/cgi-bin/archzoom.cgi/rotty@debian.org--2005/goio--dev--0.
I've done some enhancments, most notably an asynchronous I/O object and
memory-based "files".
Comment 10 Andreas Rottmann 2005-02-10 14:27:45 UTC
The GOIO library now has a new home at Gna!: https://gna.org/projects/goio/. By
now there is not much to see, but has an shared Arch repo, mailing list and
bugtracker.
Comment 11 Matthias Clasen 2008-06-16 05:32:57 UTC
stream api has arrived: gio