The Good Book

Of course, I'm talking about Jennifer Government, which came today. Somehow, this book managed to impress me despite my ludicrously high expectations of it. Imagine if The Matrix trilogy lived up to it's potential, rather than following the Star Wars model (the first movie is revolutionary due to the topic and implementation, the second movie is the best movie from an entertainment POV, and the third movie is a total letdown after the first two), and you've got Jennifer Government. I don't think it's outside the realm of possibilities to have this book end up alongside 1984 in Jr. High School reading lists.

And to finish the "fanboy" tone, I'll say that this book is good enough for me to double my typical reading speed out of sheer enthusiasm. Really, buy the damn book. :-)

GNetwork

So there's some recent efforts at creating a GObject-based IO stream, based loosely on some discussions from a year ago. Strangely, both me and a person halfway around the world started asking the participants for comments on the same idea within 24 hours of each other. Since I don't believe in coincidences, this is a big encouragement.

GNetwork ties in to provide the socket() stream object, servers, DNS and service query stuff. Best of all, the whole chain-o-objects thing can be done properly using this framework (somewhat like System.IO.Stream). It's different from other things in GNOME (GTK+ is similar), but System.IO.Stream is a nice starting point -- one that can be simplified and improved with GObject signals and properties.

GNetwork

I committed a bunch of stuff to CVS lately, mainly the big move away from using GInterface to using abstract base classes. For those who are implementing libs and such which provide GObjects, here's what I learned: GInterface is for particular APIs which can exist outside the normal object hierarchy. If you don't need the API to exist outside the normal hierarchy, or you do need the "chain-to-parent" functionality, don't use GInterface, do a GTK+-style with bunch-o-abstract-base-classes. It's actually much simpler that way.

I will say that it'd be really nice if all the various GNOME APIs for data streams were combined at some point. GLib, GStreamer, ORBit, Bonobo, and GnomeVFS all have some form of a "read from file" API, and it's silly to duplicate that in 5 places.

Ornot

Yep, still not on Orkut, though I did take advantage of the fact that everyone else is to catch up on e-mail and get going on a sexy new GNetwork framework...

GNetwork

So libgnetwork isn't going into GNOME 2.6, which is good, since rodrigo was telling me that the current arch isn't flexible enough, which means that writing a flexible one won't break too many things (I know of only a couple users of libgnetwork that aren't me).

I also spent about four hours wracking my brain on how handle detaching a GSource from it's GMainContext (so you can attach a source to an object which has a "main-context" property, then change the property and have sources just work with the new context), until I went on Google and found out you can't... on purpose. Oh well, "notify::main-context" here we come. :-(

Anarcho-Code
...or the abolition of the class hierarchy.

Of course, I'm talking about GStreamer and it's potential uses outside of the media world. What I'm thinking here is it's uses for things like XML, networking, etc.

So, for example, your encrypted jabber connection could be "GNetworkTcpSource -> GNetworkSslElement -> GNetworkProxyElement -> XmlElement -> JabberElement -> (JabberChatSink | JabberAppSink)". The "JabberAppSink" element would be an autoplugger that handles creating/destroying chats, as well as the buddy list and presence stuff. Tres cool, no?

But... (and there's always a but), I'm not sure how (or even if) GStreamer handles bi-directional pads. It'd kinda suck if you had to have "in_src" and "out_src" pads, but that's not that much worse than "received" and "sent" signals.

Update:
Welp, it appears that I've been officially on drugs (at least, according to Hallski and yakk) with the above plan. I've decided to concur after learning from thomasvs that doing bi-directional streams in GStreamer requires two separate, uni-directional streams. When dealing with networking, that's an unsurmountable difficulty, so blah.

Now, I still believe the chain-o-objects model of stream handling is the way to go (libsoup and libgnetwork both do SSL as a GIOChannel chain :-P), but I'm not about to re-implement GStreamer to find out for sure.