...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.
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.