Re: gnome-vfs/GIOChannel for parsing

[Owen Taylor <otaylor redhat com>]

On Fri, 2003-02-21 at 04:57, Michael Meeks wrote:
> On Thu, 2003-02-20 at 14:53, Havoc Pennington wrote:
> > On Thu, Feb 20, 2003 at 09:51:33AM +0000, Michael Meeks wrote: 
> > > 	My feeling is still that even if you come up with a near perfect
> > > solution, you'll be stultified at the point of actually getting it
> > > anywhere near glib.
> > 
> > If there's a good case for it, and someone makes the case, there's no
> > problem getting something in GLib.
> > 
> > The first question will obviously be "how does it relate to
> > GIOChannel"
> 
> 	Well the very asking of that question almost beggars belief as we see
> the number of non-GIOChannel streams that are crawling out of the
> woodwork. Presumably you think that GIOChannel is an acceptable
> solution?
> 
> 	Quite why we want the bulk of all the buffering, encoding conversion
> etc. etc. in the base stream abstraction I have no idea. Furthermore
> it's not a sub-classable GObject - and it's not an abstract class, it
> has a great swathe of '<private>' (but public) members, etc. So - at
> last count we had:

Note that GIOChannel was always intended as a chunk of opaque
functionality, not an extensible API. As you've correctly noted
here, some parts that are needed for subclassing are marked private.)

(Sorry, libsoup folks ...)

That being said, the basic API concept of GIOChannel is a two-object
system:

 GIOChannel   <=>    Backend stream object

And the backend stream object is relatively streamline. Stuff like
buffering and  encoding conversion is confined to the GIOChannel
object.

Regards,
                                            Owen