GNOME Bugzilla – Bug 106686
GIOChannel too limited; stream API needed
Last modified: 2011-02-18 16:13:49 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.
Created attachment 14496 [details] C src: GIOChannel emulated from GnomeVFSHandle
Created attachment 14497 [details] C src: Detect file size of GIOChannel
Created attachment 14498 [details] C src: r/w GIOChannel from r/o GIOChannel by nonpersistent memory buffering
Although Colin Walters paper seems to have vanished, it doesnt appear anyone has commented on Jan Kratochvil's patches -- doing so would be appreciated.
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)
this is a too major change to make 2.4, moved to 2.6 API.
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.
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.
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".
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.
stream api has arrived: gio