[gnet] GOIO Hacking, forking GNet code
- From: Andreas Rottmann <a rottmann gmx at>
- To: gnet gnetlibrary org, mhz altlinux org
- Subject: [gnet] GOIO Hacking, forking GNet code
- Date: Mon, 10 May 2004 19:59:09 +0200
In short: I'm contemplating over forking parts of GNet, to achieve a
more coherent, GObject-based IO framework.
Now the whole story: I did a bit of hacking on GOIO (see  and ):
* I added a GoioWatchable interface, which returns a
* I implemented (or rather stole from GNet ;)) an GoioAsync object
that sits upon another GoioObject and provides asynchronous,
buffered, read/write access ala GConn.
Additionally, you can also read/write it synchronously. This was the
itch that got me started hacking on this - there is no way to
"cleanly" read directly from the GIOChannel of a GConn, since some
data may be in its read buffer (and thus invisible to the
* Added GoioMemFile object that allows access to a GString as if it
were a file (perhaps I should base it on GByteBuffer instead).
GOIO equipped with my hacks can be found on .
Now, to make my application , which uses GConn heavily, work with GOIO,
I'd like to have an equivalent of GTcpConnection inside
GOIO. Unfortunatly, to achieve this, I'd have to fork a lot of code
So, I want to hear opinions from the GNet developers how they relate
to such an action. From my side, I think there has to be a solution to
the code duplication issue in the long run.
GOIO will be more flexible enough that it should be principially be
possible to make the GNet API a wrapper around GOIO and optionally
ship the GNet API along with GOIO or vice versa. Of course, this is
not something that would happen tomorrow, but I'd like to hear what
the GNet people think about it.
Kind Regards, Andy
Andreas Rottmann | Rotty ICQ | 118634484 ICQ | a rottmann gmx at
http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62
Make free software, not war!
] [Thread Prev