Re: [gnome-network]GNetwork Library: Directions & Roadmap

[Rodrigo Moya <rodrigo gnome-db org>]

On Sun, 2004-01-25 at 15:43 -0600, James M. Cape wrote:
> 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.
> 
there were some talks not too long ago on desktop-devel-list@ about a
streaming API, that could be extended to be a network API.

> 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
> 
right, we clearly need a base Connection class from which the other
extend. The same for messages/resquests/responses, all protocols would
be somewhat dealing with those, so an extensible mechanism that lets
client apps use the same API for each protocol would be a good move.

> 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).
> 
no, what we really want is a base class and add protocols on top of it,
with hooks for extensions to be able to trigger some stuff at any level
of the protocol. In fact, I was starting to look at SLP, as we talked
last week, and was thinking on the best way to do it. It seems to me we
really need a better extensible API.

> 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.
> 
this looks to me somewhat similar to .NET's remoting, which we should
probably also look at, since it tries to solve the same problems.

> 
> II.) DNS Queries
> 
> I'd like to combine mDNS and DNS into a "One Ring" DNS query, using the
> IpMulticast source.
>
right, I was trying to find some way to have the two more integrated, so
this sounds cool.

> 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.).
>
right, sounds great idea

>  Combining them all in this
> fashion would have the advantage of allowing app-transparent operation
> in mixed environments.
> 
yes

so, to sum up, are you meaning to use GStreamer? If so, could the
streaming stuff from GStreamer be in a separate library?

cheers