So one of the given issues with libgnetwork not getting into GNOME 2.6
was a lack of a plan. So, here's what I'm thinking for a libgnetwork 1.0
feature/arch roadmap. The goal of libgnetwork is to provide an easy-to-
code, flexible, networking class library for GNOME.
I'm writing all this to get comments, concerns, "that sucks because
ABC", "you're an idiot because XYZ", etc. messages back. If you think
I'm on crack, or this will never get into GNOME, tell me now :-).
I.) Use GStreamer?
I've been ruminating on the GStreamer (pluggable objects) v. System.IO.
Stream[1] (class hierarchy) models of handling IO, and I'm pretty sure
that the GStreamer model is slicker and far more useful in actual
applications.
The class hierarchy model, which libgnetwork uses currently, would be
used (roughly) like this an application:
GNetworkTcpConnection
+- GNetworkHttpConnection
(signals)
HtmlParser || whatever
While this is slick and useful, it's not very extensible. In ORBit,
connections can occur both in TCP and UNIX -- this requires two separate
class hierarchies doing essentially the same thing:
GNetworkTcpConnection
+- GiopTcpConnection
GNetworkUnixConnection
+- GiopUnixConnection
There is also the case where you've got a UNIX->TCP "unique connections"
daemon (useful for multiple logins on different screens sharing one
connection -- like dircproxy):
GNetworkUnixConnection
+- BlahUniqueUnixConnection
+- GIrcUnixClient
GNetworkTcpConnection
+- GIrcTcpClient
While these hierarchies could share the actual parsing code via a C API
(in fact, I believe this is how Unix does things), and share signals &
such via a GInterface, this can get ugly real fast. Do you really want
to have a dual GObject/GInterface for each level in the hierarchy to
ensure that it's not parent-class dependent? (What about putting an HTML
parser *inside* the subclass... you can't do that nicely in
libgnetwork).
Basically, *every* protocol is just a specialized set of transformations
and/or containers that are applied to the actual data the user cares
about. Which, ironically, is exactly what GStreamer is designed to solve
(albeit in a somewhat media-oriented API).
Finally, there's the threading issues. The more I look at threading
support, the more I realize I'm just duplicating what GStreamer has
already done -- making it really difficult to get motivated :-).
So, while doing something like a web browser is hard in libgnetwork:
(libgnetwork-HEAD)
GNetworkTcpConnection
+- GNetworkHttpConnection
+- MimeFilter (creates & handles data objects)
(sign
HtmlView
doing it in a GStreamer-based environment is much simpler:
GNetworkTcpSource -> GNetworkSslElement ->
GNetworkProxyElement ->
GNetworkHttpElement ->
MimeAutoplug [creates elements based on "MIME-Type:" header or
extension] PngElement | XmlParseElement | DownloaderElement ->
[HtmlViewSink, GdkPixbuf, etc.]
This means the path from network -> display is nicely bundled and all
the protocol-parsing (for each level) is handled by it's own GStreamer
element.
Not to come down too hard on System.IO.Stream, but the GStreamer model
kicks the hell out of it.
There is also the (free) parser testing ability that comes with
GStreamer usage. Specifically, you can do automated tests of your
protocol module just by shipping a test file and creating the
appropriate pipeline (so rather than GNetworkTcpSource you'd use
GstFileSource).
Since GStreamer has a "GstBin" object (like a GtkBin, but for streams),
combining things into a "GNetworkTcpBin" GstBin subclass would be
trivial to do. This way we don't have to loose any of the easy-bake
features of GNetworkConnection (automagic proxy & SSL, etc.).
Servers may benefit from using an autoplugger [kind of an automated
"watch your upstream for new 'pads' (links) and create objects based on
those), but I've not totally researched that.
Last but not least is the fact that GStreamer already handles (user and
kernel) threads well, does per-object locking, etc., and libgnetwork
does not -- most of the threadsafety things I'd started writing are
broken, and to fix them would mean doing basically what GStreamer
already does.
Some things would continue: GNetworkIpMulticast would still subclass the
UDP source, for example.
II.) DNS Queries
I'd like to combine mDNS and DNS into a "One Ring" DNS query, using the
IpMulticast source. Is this advisable? If so, how should it work? I'm
thinking that since a DNS reply is a DNS reply, I could use the res_*
(resolver lib) functions to handle constructing/parsing the replies.
With GStreamer, this could work as a "mixer", combining the results of a
DNS and an mDns query chain:
http://esco.mine.nu/software/libgnetwork/service_query_flowchart.jpg
The main issue I see with doing things that way is the interaction (or
lack thereof) with nsswitch.
III.) Service Stuff
This is the big "up-in-the-air" thing. As mentioned, applications which
want a "service browser" of some type should be able to just say "give
me a list of 'name' services in 'dn' domain" and the lib would go find
them using whatever service discovery features are available (netbeui,
slp, mdns-sd, dns-sd, AppleTalk, etc.). Combining them all in this
fashion would have the advantage of allowing app-transparent operation
in mixed environments.
As with the DNS query, this could be a "mixer" element combining the
replies to all the above individual query chains.
--
Peace,
Jim Cape
http://ignore-your.tv
"It is literally true that, like Christianity, Socialism
has conquered the world by defeating itself."
-- Alexander Berkman, ABC of Anarchism
Attachment:
signature.asc
Description: This is a digitally signed message part
