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

["James M. Cape" <jcape ignore-your tv>]

On Thu, 2004-01-29 at 00:56 +0100, Rodrigo Moya wrote:  
> 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.

Yeah, that discussion is what started the wheels turning, actually. I
decided to look into GStreamer (since that does the chain-o-objects
stream model already), but it appears that it's not suitable (see end).

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

What about this:

GNetworkData {
    GValue data;
    GType owner_type; // e.g. GNETWORK_TYPE_UDP_DATAGRAM
};

GNetworkSocket {
    Properties:
        gint status;
        guint64 bytes-received;
        guint64 bytes-sent;
    Methods:
        void send (GValueArray *pdata, gconstpointer data, glong
length);
        void open (void);
        void close (void);
    Signals:
        void received (GValueArray *pdata, void *data, gulong length);
        void sent (GValueArray *pdata, void *data, gulong length);
        bool error (GValueArray *pdata, GError *error);
};

The GValueArray args would hold GNetworkData structures[1].

send() implementations could iterate over the pdata array to find items
which they are listed as the owner type for and parse them accordingly.

For the signals, subclasses could add to pdata before chaining up.

The "error" signal returns a boolean indicating whether the socket
should remain open or close itself.

I will say that any replacement for GNetwork{Connection/Datagram} will
not be a GInterface. I've come to the conclusion that GInterface is just
what it's name implies -- a class-independent interface, not a way to do
base classes.

So how does all this sound?

[snip]

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

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
dndotnet/html/hawkremoting.asp

>From a cursory glance, it appears as though it's a GStreamer-like model,
with some kind of COM support thrown in. But I haven't looked at it too
deeply.

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

Currently, the API is shaping up as:

/* Implemented by GNetworkTcpServer
* and GNetworkUdpSocket */ 
GNetworkIpServiceIface {
    properties:
        gboolean publish;
        gchararray service;
        gchararray name;
        gchararray description;
};

GNetworkSocket ->
GNetworkUdpSocket ->
GNetworkIpMulticast ->
GNetworkDns {
    Properties:
        GValueArray *lookups;
    Signals:
        query-sent;
        query-received;
        reply-sent;
        reply-received;
    Methods:
        gulong send_query (GNetworkDnsQuery *);
        void add_service (GNetworkService *);
        void remove_service (GnetworkService *);
        GSList *list_services (void);
};

GNetworkDnsQuerySourceFlags {
    GNETWORK_DNS_QUERY_SOURCE_INVALID = 0,
    GNETWORK_DNS_QUERY_SOURCE_UNICAST = 1 << 0,
    GNETWORK_DNS_QUERY_SOURCE_MULTICAST = 1 << 1,
    GNETWORK_DNS_QUERY_SOURCE_ALL = 0x3
};

GNetworkDnsQueryFlags {
    GNETWORK_DNS_QUERY_NONE = 0,
    GNETWORK_DNS_QUERY_ADDRESS = 1 << 0,
    GNETWORK_DNS_QUERY_HOSTNAME = 1 << 1,
    GNETWORK_DNS_QUERY_MAIL_EXCHANGER = 1 << 2,
    GNETWORK_DNS_QUERY_HARDWARE = 1 << 3,
    GNETWORK_DNS_QUERY_NAME_SERVER = 1 << 4,
    GNETWORK_DNS_QUERY_DOMAIN_POINTER = 1 << 5,
    GNETWORK_DNS_QUERY_TEXT = 1 << 6,
    GNETWORK_DNS_QUERY_ALL = 0x
};

GNetworkDnsQuery {;
    GNetworkDnsQuerySourceFlags sources;
    GNetworkDnsQueryFlags flags;
    gchar *query;
};

/* Used in callbacks */
GNetworkDnsReply {
    // DNS-query-specific info w/ a copy of the original query.
};

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

The GNetworkDns object would do dual duty as a both a DNS query
interface *and* per-app mdns-sd service publishing using the add_service
() and remove_service() APIs.

GNetworkTcpServer/GNetworkUdpDatagram would add themselves when created
to some global service publishing object, which would then proxy the
"add service" method down to the actual protocol objects.

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

Well, I was originally, but it appears that GStreamer is simply too
purpose-specific to be actually useful (bi-directional streams aren't
supported, which makes networking impossible to do without sickening
hacks). IOW, chalk the whole GStreamer thing up to some bad pizza :-).


IV.) Local Interfaces

I'm also planning on moving the local interface stuff to a slicker
GObject which does it's own updating (can be turned off):

g_signal_connect (iface, "notify::bytes-received", G_CALLBACK
(update_bytes_received), rx_label); :-)


[1] GValueArray handling can sweetened to taste with API sugar, e.g.:

GNetworkData *gnetwork_data_next_by_owner (GValueArray *, GType);

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