Re: API proposal for charset code conversion at I/O

[Johannes Stezenbach <js convergence de>]

Sven Neumann wrote:
> 
> Owen Taylor <otaylor redhat com> writes:
> 
> > Now, long-term I'd like to see GIOChannel converted into something
> > much nice more full-featured. Along the lines of the
> > Java character/byte streams, or Qt's QTextStream.
> 
> Shouldn't that be a layer build on top of GIOChannels? IMHO GIOChannels
> provide a useful abstraction from UNIX sockets and pipes. Adding buffered
> IO adds an unnecessary level of complexity.
>
> > GIOChannel needs to have buffering, and a representation
> > of blocking/non-blocking IO.

Yes. IMHO buffered I/O is what you usually want. And if you don't
want it, you can turn it off (set the buffer size to zero).
That way, unbuffered I/O is a special case of buffered I/O
(like, e.g., the C stdio library handles it).

 
> We (convergence integrated media GmbH) have an IO library build on
> top of GIOChannels that provides buffering and asynchronous operation
> in the GMainLoop. If you are interested, contact me and I will make
> that code available to you. It's scheduled for release under the LGPL
> anyway.

The most important aspect of GIOChannel for the convergence I/O
library is its integration into the GLib event loop to allow
asynchronous I/O.

Owen's example concentrates on some filter capability
integrated into GIOChannel, which I would rather see in
a layer on top of GIOChannel.

The convergence I/O library has the following:
- a dispatcher class, which maps the I/O events (GIOCondition)
  from the event loop (GIOFunc passed to g_io_add_watch())
  to virtual member function calls (handle_read(), handle_write() etc.).
- a buffer class derived from the dispatcher class which
    a) allows data buffers to be queued for sending whenever the
       GIOChannel becomes writable
    b) buffers incoming data and optionally scans it for a given
       record terminator (which can be just \n), and map that
       to virtual member functions (incoming_data(), found_terminator())

The design of the buffer class was intended to be the base of
a producer/consumer model, were data to be sent is produced by a
producer object (which has a more() method to produce more data),
and consumed by a consumer object, as soon as the GIOChannel becomes
readable/writable, i.e. without the need to buffer large chunks
of data.

The goal is to be able to send GObjects serialized as XML via
a GIOChannel socket connection, and do the XML generation and
parsing with as little memory as possible.

However, our library is still incomplete...


Johannes