Yay, finally!

Minor point: would be great if SOCKS4/5 support was taken into account in the design from the start, if it's not already.

More things to worry about:

  * Windows support. (WinSock is pretty close to the BSD sockets API, so
    this isn't that hard, unless you want to expose file descriptors in the
    API, at which point you have to start dealing more with the difference
    between different kinds of file descriptors in win32 glib.)

    SoupAddress (or really soup-dns.c mostly) and SoupSocket may have some
    stealable code here. (soup-dns is a bit of a disaster; you don't want
    to steal its API/architecture, just the doing-the-actual-work bits)

  * Asynchronous DNS. Libsoup does this by using threads, but it would
    probably be better to suck in one of the async resolver libraries.
    (http://daniel.haxx.se/projects/c-ares/ has an LGPL-compatible
    license). (Of course, this may mean that the libsoup windows dns
    code is completely useless to you. :)

  * SSL. Worst case, it should at least be possible to write a subclass of
    GSocket that just reimplements everything without using any of the
    base GSocket's code, I guess... 

    Some applications need the ability to switch a socket from non-SSL to
    SSL after sending data. (Eg, when using the CONNECT method in HTTP.)
    I don't think the reverse occurs.

    I'm in the process of trying to come up with an abstraction around
    server-certificate-validating and client-certificate-providing callbacks
    that would work with both NSS and GnuTLS. (Hm... and windows? Blah...)

For async hostname resolution, i think using a custom resolver is a bad idea. It will never integrate correctly with the system resolver (nss, etc).

On linux we should use the glibc asynchronous resolver (getaddrinfo_a) and on other system any other native lookups, and if there is no native async resolver, implement one using threads.

FWIW, GNet probably also has some copy'n'paste-able bits for win32 and bits that make things build and work on more exotic unixes or older linuxes/glibcs, including configure checks and all that (libsoup might have that too of course, I haven't checked).

Hi everyone,

Didn't even know this bug existed until today :-). I'm working on this at http://www.cs.mcgill.ca/~scormi3/git/gnio.git/

Couple of quick comments, the current (very basic) class layout is:

GInetAddress
 |- GInet4Address
 |- GInet6Address

GSocketAddress
 |- GInetSocketAddress (contains GInetAddress and port)

GResolver (provides async resolving with threads currently)

GSocket (low-level, no async, just wrapper around BSD sockets)

GTcpServer (accept returns a GTcpClient)

GTcpClient (connect, get NetworkStreams)

GNetworkInputStream, GNetworkOutputStream for API's similar to GIO

This is (I hope!) what we decided on in #nautilus. I grabbed most of the cross-platform resolving stuff from GNet (looks like Soup also copied from them). I've also tested all of this on Windows, and it seems to work fine (apart from WSAStartup, which needs to be called from the class_init's of all the classes that need winsock).

As for SSL, although I've used it in .NET, I really don't know enough about the details and the requirements to come up with a good API, but once its fleshed out it shouldn't be too hard to write :-).

(In reply to comment #5)
> GTcpServer (accept returns a GTcpClient)
> 
> GTcpClient (connect, get NetworkStreams)

Three slightly contradictory comments on those names:

  - Standard glib/gobject/gnome style would be "GTCPClient" and
    "GTCPServer". (ie, don't convert "TCP" to titlecase)

  - The fact that the client and server both use a GTcp*Client* for
    communication is sort of confusing. ("GTCPConnection" maybe?)

  - Other than the fact the constructors take GInetSocketAddresses
    rather than GSocketAddresses, it looks like these classes could be
    used for unix domain sockets as well as TCP sockets, so maybe they
    should either be genericized a little, or else turned into subclasses
    of a generic base class. ("GSocketConnection"?)

(In reply to comment #6)
>   - Other than the fact the constructors take GInetSocketAddresses
>     rather than GSocketAddresses, it looks like these classes could be
>     used for unix domain sockets as well as TCP sockets, so maybe they
>     should either be genericized a little, or else turned into subclasses
>     of a generic base class. ("GSocketConnection"?)
> 

I've renamed GTcpClient -> GTCPConnection and GTcpServer -> GTCPServer and made them both subclasses of GSocketConnection and GSocketServer respectively - now they are just wrappers that provide hostname lookups.

I also started documenting the API; you can find the gtk-doc output at http://www.cs.mcgill.ca/~scormi3/gnome/docs/gnio

Also, for Unix domain sockets, should it be GUnixSocketAddress or GLocalSocketAddress? (I think Windows might support AF_LOCAL in some strange way, so UnixSocketAddress may be misleading...)

> I think Windows might support AF_LOCAL in some strange way

No, it doesn't.

There are Named Pipes, which are to some degree conceptually similar, but they are completely different. They have nothing to do with sockets, i.e. WinSock, for instance. With a wrapper at a high enough level, possibly the same "GLocalSomething" API could wrap both Unix domain sockets and Named Pipes. That would rock.

Quick update: I've had a bit more time to work on this. I cleaned up the code a bit and also wrote a quick URL-retrieving library (which I'm calling gurl for lack of a better name ;-)) in the spirit of Python's urllib2. It's written in Vala to make it easier to refactor, and uses GIO's extension points so that handlers could provide support for SSL/proxies without having to link to any external libraries. Anyways, if anyone is still interested, I've moved the code to my new server; you can get it at http://sciyoshi.com/git/gnio.git/ and there's a gitweb interface at http://sciyoshi.com/gitweb/.

Forgot to mention that I also have an initial patch for libsoup that makes SoupAddress a thin wrapper around GSocketAddress, but "porting" anything else in Soup to use gnio would be a bit harder without changing the API, since unlike gnio, libsoup lets you pick which GMainContext to use. Does anyone know how many people are actually using this feature of libsoup? (for example, soup_address_resolve_async_full doesn't really seem to be used anywhere)

Threaded applications will likely want the ability to change the main loop (if they are not using blocking I/O). However, it's generally not very interesting for desktop apps, as they tend to use only one thread, and if they use other threads, they use them to do blocking I/O.

That said - you're using a main context anyway, so it shouldn't be hard to add it to your socket structs and make it settable - possibly as a construct-only property?

(In reply to comment #10)
> Forgot to mention that I also have an initial patch for libsoup that makes
> SoupAddress a thin wrapper around GSocketAddress, but "porting" anything else
> in Soup to use gnio would be a bit harder without changing the API, since
> unlike gnio, libsoup lets you pick which GMainContext to use. Does anyone know
> how many people are actually using this feature of libsoup?

It is being used. I'm not sure how much. The original use case was using a SoupServer in a separate thread. (SoupServer doesn't support blocking/sync I/O, so you can't use SoupServer in a separate thread without being able to set its GMainContext.) IIRC it's also used in the gstreamer libsoup plugin.

> (for example,
> soup_address_resolve_async_full doesn't really seem to be used anywhere)

That's libsoup 2.2 api. It's just soup_address_resolve_async() now. And in both 2.2 and 2.4, it's mostly used by SoupSocket, because most libsoup-using apps don't manipulate SoupAddresses by hand.

> ..., since unlike gnio, libsoup lets you pick which GMainContext to use.
> Does anyone know how many people are actually using this feature of
> libsoup? (for example, soup_address_resolve_async_full doesn't really
> seem to be used anywhere)

I haven't used the feature in libsoup, but I've spent quite a bit of time converting GNet to support this a while ago, exactly for use cases like in GStreamer.

I think this is a pretty essential feature and it would be good if gnio supported it as well IMHO.

i filed a separate bug (bug 548466) for DNS support, since that could potentially be done before the rest of this

I'm interested in getting this done too. Any progress?

Well. I've forked the gnio and reworked the class hierarchy concerning GSocket. However it seems that I created a different approach - influnced both by GIO and Java IO. Here's the plan - not what I've already implemented:

GSocket - client-side
  GTcpSocket
  GUdpSocket
  GFilterSocket
    GTslSocket
  GLocalSocket
  GUnixSocket
  GWin32Socket

GServerSocket
  GTcpServerSocket
  GUdpServerSocket
  GFilterServerSocket
    GTslServerSocket
  GUnixServerSocket
  GWin32ServerSocket

The motivation was to hide all internals and do not expose it as a top-hierarchy element (not mentioning limiting number of methods).

 

I've forgot to add git:
http://github.com/uzytkownik/gnio/tree/master (webpage)
git://github.com/uzytkownik/gnio.git (repo)

*** Bug 438432 has been marked as a duplicate of this bug. ***

It might make sense to have a look at GOIO (http://home.gna.org/goio/). It is now stalled, but has probably some code to steal (it's in part based on GNet and also LGPL-licensed). I've put a snapshot tarball at http://download.gna.org/goio/goio-0.1.2.tar.gz so you don't have to bother with tla/baz.

(In reply to comment #19)
> It might make sense to have a look at GOIO (http://home.gna.org/goio/). It is
> now stalled, but has probably some code to steal (it's in part based on GNet
> and also LGPL-licensed). I've put a snapshot tarball at
> http://download.gna.org/goio/goio-0.1.2.tar.gz so you don't have to bother with
> tla/baz.
> 

IMHO GOIO is very different (internally) from what should be achived. With the exception of datagrams the usage of G{Input,Output}Stream. Today the bug #555465 has been fixed so it is likely that I'll improve my fork in this matter.

Anyway - what I belive is the most important is the interface. Both GOIO and orginal GNIO (as well as perl, python and other POSIX-influenced) decided to implement the thin wrapper over POSIX Socket interface. Personally I prefere in OOP to have more Java-like approach (separate classes for Datagram and Stream, hide most internals etc.) as I fell it is more HL.

> With the exception of datagrams the usage of G{Input,Output}Stream.

Sorry, I could not understand that.

Regarding the stealable code: It's true that GOIO has quite a different API to what's already in GIO, but I think at least some of the InetAddr and resolver code could be mingled into GNIO.

(In reply to comment #21)
> > With the exception of datagrams the usage of G{Input,Output}Stream.
> 
> Sorry, I could not understand that.
> 
> Regarding the stealable code: It's true that GOIO has quite a different API to
> what's already in GIO, but I think at least some of the InetAddr and resolver
> code could be mingled into GNIO.
> 

I think bug #548466 already has a lot of good code that can be used for the address resolving, seems like they're leaning towards including libasyncns in gio. I'm planning on replacing the GResolver currently in gnio with Dan Winship's implementation, since it seems like a much more reliable approach.

a few more notes:

I mentioned SCTP in bug 548466. I haven't totally figured SCTP out yet, but for our purposes, the big thing that's very different from TCP and UDP is that you can have multiple independent I/O streams on a single socket. So in gnio terms, you'd need some way on a SCTP GSocket to peel off additional GSockets (which might be different from the "parent" sockets in some way?). As I said, I haven't totally figured out the details yet... (And I'm not saying this is a "we must support this in 1.0" thing, it's a "it might be clever for us to figure out what additional API it *would* need, and make sure we can fit that in cleanly later if/when SCTP starts to take off".)

Another thing that may (or may not) have API impact is proxy support. There are two kinds of non-protocol-specific proxies that it would be nice if we could support at the gnio level: SOCKS, and HTTP CONNECT. They are more-or-less equivalent, except that SOCKS is easier to deal with because it's actually meant to be used this way, whereas using HTTP CONNECT requires potentially dealing with a few (but not too many) extraneous bits of HTTP syntax. In either case, once the remote tunnel is established, the proxy becomes completely transparent, so from an API standpoint, we just need to answer questions like, "how do you tell gnio to use a proxy?", and "when you call g_socket_connection_get_address() on a proxied connection, does it return the proxy server address or the remote server address?", etc.

I'm planning to redesign my fork of GNIO to allow such 'strange' things as SCTP more naturally (changes in branch).

GConnection - Connection for conection-based protocols
  GStreamConnection - Stream connection (contains input/output stream)
  GPacketConnection - Packet connection (allow send/recive)

GSocket - Abstract socket
  GMessageSocket - Abstract socket for packet-based protocols
    GDatagramSocket - Abstract socket for conectionless protocols
      GUDPSocket - An UDP socket
    GPacketSocket - Abstract socket for packet protocols (realible)
      GSCTPPacketSocket(?) - An SCTP Stream socket
  GStreamSocket - Abstract socket for stream protocols
    GSingleStreamSocket - If the protocol has only one stream
      GTCPSocket - An TCP Socket
    GMultiStreamSocket - If the protocol has many streams (probably not needed)
      GSCTP[Stream]Socket - An SCTP Stream Socket

I've skim draft-ietf-tsvwg-sctpsocket-18.txt and it seems that the SCTP recv behaves more stream-like (do not trunkate messages). I'll have to find out if it is possible to trunkate for purpose of GSCTPPacketSocket (that's the reason of '?' and [Stream]).

1. I guess that transparency requires to return the remote server. Possibly g_socket_get_proxy or something like that might become included.
2. I'm not sure how to implement it but:
- In gnome application it should be (preferable automatically) fetched from GConf
- On other enviroments it should be getted from them if possible
- Otherwise the application should decide (in any case it should have the ability to ovrride it)
3. Sorry I'm asking. But is it decieded that Samuel's GNIO is going to be included? I prefere more abstract API so I maintain a separate library (some code is shared). However I'd see no point in doing it if this matter was already decided. 

Seeing as how Dan has already started integrating GResolver into gio directly, I've decided to clone his glib repository and work on gnio directly inside gio as well. Just wondering if this is a good course of action, any comments/suggestions?

The git repository is at http://sciyoshi.com/git/glib.git/ (gitweb at http://sciyoshi.com/gitweb/glib.git/)

Samuel: 
I think that is a good idea, makes it easier to import it later.

Also, dan already imported some of the gnio classes, so the set of gnio-specific classes gets smaller.

Maciej:

I don't quite understand why you all those subclasses would be interesting? In the end the implementation of them are all the same, as the underlying socket concept supports all those in on object. Are there many subclass specific methods in your design?

Also, I'm not sure having a GPacketConnection class makes sense. datagrams are not necessarily handled like one-to-one "connections". Sometimes you send packets to and receive from multiple endpoints. (Unless you're intending to use that class only for SOCK_SEQPACKET).

(In reply to comment #27)
> Maciej:
> 
> I don't quite understand why you all those subclasses would be interesting? In
> the end the implementation of them are all the same, as the underlying socket
> concept supports all those in on object. Are there many subclass specific
> methods in your design?
> 

One class for concept. IMHO if it used differently it should be describe differently.

1. In the thin API I guess that the different methods have different meanings. For example:
- For recv/send if the connection is backet-based it reads whole packet otherwise the part of stream
- Accept have different meaning for SCTP and servers (it do the same but it's different concept)
2. In more HL languages (such as Vala) the separation will make the errors harder. UDP socket will not be used as stream socket. Also it will improve self-documenting of code.
3. What will look like using get_{in,out}put_stream on UDP Socket. Return NULL? UB? A 'normal' stream (however if read is not 'synchronised'[1] it may behaviour strange)?
4. Most methods are similar in my design but they indicates different usage. For example to use StreamSocket one have to communicate via read/write of G{Input,Output}Stream. It is not dramatically different from using send/receive except that the first guarantee the stream features of connection (no data loss, can be read in arbitrary part) and second the features of packet (packets are read as whole). 

So basicly I'm more concentreted on the user's point of view not the implementation of it.

[1] And if it will be BufferedInputStream it will not

> Also, I'm not sure having a GPacketConnection class makes sense. datagrams are
> not necessarily handled like one-to-one "connections". Sometimes you send
> packets to and receive from multiple endpoints. (Unless you're intending to use
> that class only for SOCK_SEQPACKET).
> 

Only for 'SEQPACKET'. For conectionless it, as you said, useless. 

PS. I've dropped 2 classes (GMessageSocket and GMultiStream).

(In reply to comment #27)
> Maciej:
> 
> I don't quite understand why you all those subclasses would be interesting? In
> the end the implementation of them are all the same, as the underlying socket
> concept supports all those in on object. Are there many subclass specific
> methods in your design?
> 

5. Also it would be handy with 'joined' sockets[1]. The GJoinedStreamSocket for example could try to each of the possible destinations one by one. But such operations are artificial for the GJoinedDatagramSocket.

[1] Joined socket is socket 'connected'/'binded' etc. to several interfaces - not necessary using 

PS. In my previous comment I belive I was wrong about accept.

Hi everyone

I've been working on GNIO (and mostly discussing it with Christian, Samuel, Dan and Alex on IRC).  I figure I should update this bug with info about what's going on.

My branch is here:

  https://desrt.ca/gitweb/?p=gnio

(Samuel's branch was tracking it for a little while but seems to have stopped)

There is considerable flux right now (new files and classes coming and going a lot), so I'm not merging it into glib yet.  I'll do that when things are more stable.

You need to install danw's 'gresolver3' branch of glib in order to build and use this.  It also uses gobject-introspection and vapigen but that part should be easy to hack out if you don't like it.

Some basic ideas that were talked about on IRC that I've implemented in this branch:

 * A basic input/output stream interface is handy.  "GIOStream".  This has
   get_input() and get_output() functions that return GInputStream and
   GOutputStream

 * GSocketConnection (base class of GTCPConnection) is a GIOStream.

 * A GSocketConnection always represents a -connection-.  If you are not yet
   connected, then no SocketConnection object exists.

 * GTCPClient is back as the object you have before you connect.  It basically
   facilitates the asynchronous creation of GTCPConnection objects.  It also
   will support things like binding to a specific local address for outgoing
   connections.

   It's like (pseudo):

    client = new TCPClient ()
    connection = client.connect ("gnome.org", "http")

   then you can use the GIOStream interface on connections:

    in_stream = connection.get_input ()
    out_stream = connection.get_output ()

 * There is TLS support.  It works. (oh ya: you need gnutls to compile too) :)

 * Lots of fixups to make the asynchronous and cancellable code work properly.

 * All the stuff in danw's 'upstream' branch has been ripped out.

I'm working on this full time, so development speed is fairly decent.  Here's what I'll be doing in the coming weeks:

 * Addressing various style issues (like Tcp -> TCP)

 * Adding support for checking TLS credentials (with CA support)

 * Adding support for awesome things (like fd passing) to GUnixConnection

 * Server side stuff (I think I have a reasonable idea about this)

 * Mainloop selection

Here's my general idea for server-side (comments welcome):

 * In general, there needs to be an easy way to listen on more than a single
   socket, but this should be done without disrupting the simple case where
   people just want to accept() on one socket.

 * GSocketServer will be renamed GSocketListener and remain the same

 * Subclasses GTCPService and GUnixService.  These subclasses will know how
   to create the proper type of connection (eg, GTCPConnection) objects.

 * New class GSocketService will contain a list of GSocketListeners

 * GSocketService will emit an "incoming" signal when one of those listeners
   has an incoming connection.  You can either connect to this signal or
   subclass GSocketService and implement the vtable method.

 * GThreadedSocketService will handle the "incoming" signal by spawning a
   thread (or maybe using a thread pool?) and emitting the "run" signal in
   that thread.  Again, you can connect "run" or subclass and implement.

My thoughts on mainloop selection:

Most people don't care, so they shouldn't be punished by having an extra "NULL, " to type for every call (which would be the result of adding a GMainContext argument to each method).

Instead, I propose to implement two functions that will be something like:

  gnio_push_main_context (gmaincontext *)
  gnio_pop_main_context ()

This will store a stack of main contexts in a variable in thread local storage.  That way, if you want to get your callbacks in another context, you can do:

  gnio_push_main_context (my_context);
  g_foo_frob_async (foo, ...);
  gnio_pop_main_context ();

or if your thread always wants to use the same context then you can just push one when your thread is created and forget about it.

The same thing could be implemented with a get/set sort of setup (which would be easier to implement) and then you could write:

  old = gnio_get_ctx ()
  gnio_set_ctx (my_context)
  ...
  gnio_set_ctx (old)

I'm not sure what one is a better idea.

In any case, it might make a good deal of sense to share this functionality across all of GIO.

It might also make sense to push this into core glib itself (ie: change the meaning of the 'default context' when you give NULL for any glib call that takes a GMainContext *) but I haven't really given a lot of thoughts to the implications of that and I have a hunch that it might be A Very Bad Idea(tm).

The end.

Looking from a GL pov, per-thread global variables seem like a somewhat bad idea when you start layering libraries on top of each other that might want to use different values. Not sure if using a stack instead of a global value is a proper fix for this though.
Wouldn't it just work to pass the context as a construct-only property to constructors and then have something like *_new_with_context() ?


Are there any plans to have some major users of this code ported before pushing this into glib? This code looks a lot like "we don't have a clue how the API should look" so this sounds like a very good idea to avoid API messups that we'd have to support for N years...

(In reply to comment #6)
> (In reply to comment #5)
> > GTcpServer (accept returns a GTcpClient)
> > 
> > GTcpClient (connect, get NetworkStreams)
> 
>   - Standard glib/gobject/gnome style would be "GTCPClient" and
>     "GTCPServer". (ie, don't convert "TCP" to titlecase)

(In reply to comment #30)
>  * Addressing various style issues (like Tcp -> TCP)

I don't have the feeling that all caps words (3 and more characters) are really common in type names of the GTK+ stack. As an example, GVfs doesn't use all caps - not to mention that we do use GtkWidget, not GTKWidget. Although I think that longer all caps words are hard to read, I don't want to start any bikeshedding here. My main point is consistency, and with the GVfs example it should be called GTcpClient.

(In reply to comment #31)
> Looking from a GL pov, per-thread global variables seem like a somewhat bad
> idea when you start layering libraries on top of each other that might want to
> use different values. Not sure if using a stack instead of a global value is a
> proper fix for this though.
> Wouldn't it just work to pass the context as a construct-only property to
> constructors and then have something like *_new_with_context() ?

If set/get is used the intention would be to have a strict "if you set it, you have to put it back to what it was" rule (ie: basically forcing a stack-like semantic anyway, but using the C stack instead of maintaining one internally).

The one exception to this rule would be if you were the person responsible for creating the thread -- then you can set it to whatever you like.



about caps:
some more examples juergbi mentions on IRC just now:

05:04 < juergbi> desrt: fwiw, Qt and .net both use Tcp naming
05:04 < juergbi> and Xml, for example (as does glade and libxml)

(In reply to comment #30)
>  * Subclasses GTCPService and GUnixService.  These subclasses will know how
>    to create the proper type of connection (eg, GTCPConnection) objects.

You mean "Server" here and everywhere else you wrote "Service", right?

>  * GThreadedSocketService will handle the "incoming" signal by spawning a
>    thread (or maybe using a thread pool?) and emitting the "run" signal in
>    that thread.  Again, you can connect "run" or subclass and implement.

Yeah, I was going to add something like this to SoupServer. Using GThreadPool is nice because you can let the app choose to use a non-exclusive thread pool, and then it will share threads with other thread pools too (like GResolver's).

> In any case, it might make a good deal of sense to share this functionality
[non-default GMainContexts]
> across all of GIO.

Yes, I don't think there's anything specifically gnio-ish about it. (Though the opposing argument is "it's no more necessary in gnio than it is anywhere else".)

> It might also make sense to push this into core glib itself (ie: change the
> meaning of the 'default context' when you give NULL for any glib call that
> takes a GMainContext *) but I haven't really given a lot of thoughts to the
> implications of that and I have a hunch that it might be A Very Bad Idea(tm).

Yeah, eg, code that assumes that it can use g_idle_add() to dispatch something to the main thread would break.

(In reply to comment #31)
> Looking from a GL pov, per-thread global variables seem like a somewhat bad
> idea when you start layering libraries on top of each other that might want to
> use different values.

If you make it be a thread-default context rather than a context stack, then that problem goes away. (The code that created the thread would set the new context, and everything else running in that thread would just use the default.)

> Wouldn't it just work to pass the context as a construct-only property to
> constructors and then have something like *_new_with_context() ?

This is how libsoup does it. But this creates API bloat which Ryan was trying to avoid.

> Are there any plans to have some major users of this code ported before pushing
> this into glib? This code looks a lot like "we don't have a clue how the API
> should look" so this sounds like a very good idea to avoid API messups that
> we'd have to support for N years...

It looks like it will be ready to try out soon, but the plan is for it to not go in to glib 2.20 (GNOME 2.26). So people will have several months to try it out before it could hit a stable release.

(I'm not sure if anyone is actively planning to port to it as soon as it's ready; I'm planning to use GResolver for libsoup, but not gnio, because it would be a pain to rewrite the HTTP code to use callback-style I/O rather than EAGAIN-style I/O.)

(In reply to comment #32)
> I don't have the feeling that all caps words (3 and more characters) are really
> common in type names of the GTK+ stack.

Hm...
3-or-more-caps: GDoubleIEEE754, GFloatIEEE754, GdkEventDND, GtkClipboardURIReceivedFunc
non-caps: GVfs, GdkRgbCmap, GdkRgbDither, GtkLinkButtonUriFunc

And the final score is: Tie! :-/

However, almost all 2-character acronyms are capitalized (GIOChannel, GdkGC, GtkIMContext, GtkUIManager, etc) and it seems weird to say that the rule is "2-letter acronyms are capitalized but longer ones aren't".

(In reply to comment #34)
> (In reply to comment #30)
> >  * Subclasses GTCPService and GUnixService.  These subclasses will know how
> >    to create the proper type of connection (eg, GTCPConnection) objects.
> 
> You mean "Server" here and everywhere else you wrote "Service", right?

Yes, I did.  But on second thought, I actually mean "Listener".  Serves me right for using bugzilla at 4am. :)

> It looks like it will be ready to try out soon, but the plan is for it to not
> go in to glib 2.20 (GNOME 2.26). So people will have several months to try it
> out before it could hit a stable release.

Actually, please try it now.  Client-side stuff should be working.  See client.c for an example.


> (In reply to comment #32)
> > I don't have the feeling that all caps words (3 and more characters) are really
> > common in type names of the GTK+ stack.
> 
> Hm...
> 3-or-more-caps: GDoubleIEEE754, GFloatIEEE754, GdkEventDND,
> GtkClipboardURIReceivedFunc
> non-caps: GVfs, GdkRgbCmap, GdkRgbDither, GtkLinkButtonUriFunc
> 
> And the final score is: Tie! :-/
> 
> However, almost all 2-character acronyms are capitalized (GIOChannel, GdkGC,
> GtkIMContext, GtkUIManager, etc) and it seems weird to say that the rule is
> "2-letter acronyms are capitalized but longer ones aren't".

I'm just not going to touch the code wrt. capitalisation for now.  We can fight about this one later. :)

(In reply to comment #34)
> > Are there any plans to have some major users of this code ported before pushing
> > this into glib? This code looks a lot like "we don't have a clue how the API
> > should look" so this sounds like a very good idea to avoid API messups that
> > we'd have to support for N years...
> 
> It looks like it will be ready to try out soon, but the plan is for it to not
> go in to glib 2.20 (GNOME 2.26). So people will have several months to try it
> out before it could hit a stable release.
> 
> (I'm not sure if anyone is actively planning to port to it as soon as it's
> ready; I'm planning to use GResolver for libsoup, but not gnio, because it
> would be a pain to rewrite the HTTP code to use callback-style I/O rather than
> EAGAIN-style I/O.)
> 
As far as I know there were multiple issues with the GIO APIs that became apparent once people started actively porting their apps from gnome-vfs. But that only happened when the API was already released, so there was no chance to fix it.
At least Alex ported Nautilus, so we had one big consumer of it working.

I'd like to avoid this with GNIO, especially because I think callback-style I/O is a very bad idea. And I'd be very happy if there were enough consumers of the API to prove e wrong instead of a frozen API that proves me right.

Sorry I'm asking this question once and once over (it stills remain unanswered). I prefere more strongly typed way (hierarchy of sockets instead of single class) - but I see no point in developing a library if it is known it is not going to be used. If it is decided that the another approach is going to be merged to glib - please say so - I'll be able to focus on other projects. If it is not yet decided I'll try to show by developing an advantages of this approach.

(In reply to comment #36)
> I'd like to avoid this with GNIO, especially because I think callback-style I/O
> is a very bad idea. And I'd be very happy if there were enough consumers of the
> API to prove e wrong instead of a frozen API that proves me right.

One of the goals of GNIO, for me at least, is to make the API as GIOish as possible.  Languages like Vala have (or are getting) good support for doing GIO-style async IO and doing things in a way that's very close to how GIO does them will make the library much easier to bind.

Even if you don't agree with some of the specific decisions that GIO made, I think that now that they are made, there is great value to consistency.

> (I'm not sure if anyone is actively planning to port to it as soon as it's
> ready; I'm planning to use GResolver for libsoup, but not gnio, because it
> would be a pain to rewrite the HTTP code to use callback-style I/O rather than
> EAGAIN-style I/O.)

I haven't really had time to look at the recent code. But at least the initial version of the design had the GSocket lowlevel object expose more or less an abstracted version of the system socket API. I.e. it has send(), recv() and 
g_socket_create_source() so that you can get a callback when you can read or write. Then the higher level streams turn these into callback style i/o.

So, you can use at least some of the gnio code. That way you could maybe avoid some portability code and get the nice features for the other non-streaming stuff (connecting, accepting, etc).

Oh, and the thread-local stack of context is generally the approach I have proposed for handling multiple main contexts too.

We should do that for all of gio though, not just the gnio part.

Well, thread local stack or maybe just a thread local default. I dunno if a stack is required really, it might just complicate stuff.

1. For those who would like to know - desrt git repository is git://git.desrt.ca/gnio (at least for my the http one is showing 404)
2. I like this for API enought to close my fork and (when/if I'll have the time) try to contribute to the mainline
3. I'm not sure if and how it is possibly and how to implement it. But I come to an idea of listining only on a 'sphere'/'area':
- Localhost - 127.0.0.1/::1 only. For services which needs network stack for local communication (possibly to allow older applications to connect)
- Trusted LAN - Expose only in trusted LAN - for example HOME. Sometimes I want to have pulseaudio exposed to my home LAN but I don't want to have it exposed in local cafe.
- LAN - For all types of LAN - good for for example network games as I can play with a friend in local cafe but there is no need of exposing it constantly to the internet
- Internet - A normal service

Unfortunatly I'm afraid that:
- Not on all system such information can be gather (but it can be relativly simple to distinguish LAN/Internet ip)
- On GNOME it would need to access NetworkManager - which uses glib, not need to be installed at all etc. 
- The NM itself would need to be modified - to expose information if it connected via ppp - so it is internet - or by wifi - to which a 'trusted' checkbox would need to be added

eep.  sorry about the gitweb being down.  i tried to install reviewboard last night and ended up totally messing up my http server config.  should be better now :)

about the idea of binding to certain 'spheres', i think that's a god idea.   we were talking about this on IRC before, too.

it's true that gathering information in a portable way is impossible, but glib exists in order to provide portable interfaces to underlying system-specific things.  perhaps one of the things that gnio is responsible for abstracting is how to gather a list of interfaces on a system (possibly even reporting when this changes).

(In reply to comment #43)
> eep.  sorry about the gitweb being down.  i tried to install reviewboard last
> night and ended up totally messing up my http server config.  should be better
> now :)
> 

Thanks

> about the idea of binding to certain 'spheres', i think that's a god idea.   we
> were talking about this on IRC before, too.
> 

Well. To be honest - could the discussion be moved to mailing list/this bug.
1. It is much easier to participate for those who are not in mainline - you don't have to be avaible 24 h/day.
2. It's more archived

> it's true that gathering information in a portable way is impossible, but glib
> exists in order to provide portable interfaces to underlying system-specific
> things.  perhaps one of the things that gnio is responsible for abstracting is
> how to gather a list of interfaces on a system (possibly even reporting when
> this changes).
> 

Well. Sometimes the application may care about specific interfaces but I don't think it will be the mainline. I guess that most application will just need to choose from those 4.

We may for example use NM/whatever on GNU/Linux and fallback to 'guessing' on other systems.

I tried to contact with it Ryan Lortie but he didn't respond so far:
"1. I have a problem as it seems that the gnio requires patched vala (or
rather gio-2.0.vapi generated against gresolver3 branch). I have
problems with generating it myself. Is it possible to get it from
somewhere?
2. Do you mind to create a TODO list? I'd like to participate in this
project but I know that there has been some discussion on irc (well - I
know of course bug report)."

(In reply to comment #45)
> I tried to contact with it Ryan Lortie but he didn't respond so far

i was travelling.



i have pushed a series of changes into gnio that should make it much easier to build.  i added a README explaining the new process.

all vala/gobject-introspection stuff is now optional.  if you do want to use vala, you will vala from the future (ie: after bug 572554 and bug 572474 are closed and a new release is made -- should be later today).

as for TODO, this bug is a fairly good log of that.

Created attachment 129189 [details] [review]
0001-Fixed-searching-of-g_inet_address_is_any.patch

(In reply to comment #46)
> (In reply to comment #45)
> > I tried to contact with it Ryan Lortie but he didn't respond so far
> 
> i was travelling.
> 
> 

Ok. I don't blame you ;)

> 
> i have pushed a series of changes into gnio that should make it much easier to
> build.  i added a README explaining the new process.
> 

Well. The g_inet_address_is_any is not found in any standard libraries. AC_CHECK_FUNC checks only libc (patch attached).

> all vala/gobject-introspection stuff is now optional.  if you do want to use
> vala, you will vala from the future (ie: after bug 572554 and bug 572474 are
> closed and a new release is made -- should be later today).
> 

Oh. I don't bother since I use normally vala from SVN ;)

> as for TODO, this bug is a fairly good log of that.

Personaly I would prefere TODO file as it is more sorted and easier to find undone things. I'll skim the bug tomorrow.

Ops. I forgot to ask if git patches should come here or be sent via mail.

(In reply to comment #48)
> Ops. I forgot to ask if git patches should come here or be sent via mail.

email is fine, but preferably open new bugs.  i created a "network" component for glib and it is appropriate to file bugs about gresolver or gnio there.
in any case, further issues should probably not be addressed on this bug because it's already getting very long.

(In reply to comment #47)
> Well. The g_inet_address_is_any is not found in any standard libraries.
> AC_CHECK_FUNC checks only libc (patch attached).

The LIBS line ensures that libgio is checked properly.  Unfortunately, your patch breaks the build for me.  It causes the following compile to be attempted on my system:

configure:12226: gcc -o conftest -g -O2   conftest.c -lgio-2.0 -L/usr/local/lib -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0    >&5

which gives:
/home/desrt/code/gnio/conftest.c:33: undefined reference to `g_inet_address_is_any'

because -lgio-2.0 appearing before -L/usr/local/lib causes the system libgio (/usr/lib) to be included before mine, and of course g_inet_address_is_any is not defined here.

i think the LIB approach, even though it is uglier than your approach is required here.  i copied it out of gtk's configure.  if you can find a less awful way to do it then patches are definitely appreciated (but in a new bug report, please) :)

I am wondering if there is a the potential for a Google Summer of Code project with GNIO. Today is the last day to apply. 

I was looking at the GNIO code and it looks like there are a number of features that could be added to the TLS capabilities. It doesn't look like it has much as far as setting a key store and the location as far as doing certificate verification. In addition, it uses anonymous Diffe Hellman. Not that this is a bad thing, but certainly it appears that many more features from TLS could be added. 

I am a grad student in computer science at Sac State. I was looking at doing Google Summer of Code this summer. I downloaded the gnio code, compiled it and tested it out. I researched the Gobject construct some and I was looking at putting the TLS code into GNIO. Last summer, I worked on another project with the intent of putting TLS into the server code which used the gnet library. In the end, I did an ugly hack where I just grabbed the socket out the gnet connection and connected the TLS to it. In the end, I determined it would be much better to find a library that would fit into the server on which I was working. It appears that GNIO would be that project.  

Last semester, I took a class in cryptography, so I refined my skills a bit. Now, I have bought the Official Gnome developers Guide, and the Foundations of GTK development. Any suggestions as far kicking this into a project for GSOC would be appreciated. 

Now when gresolver is merged into glib may be it is time to put gnio into branch (my branch solving bug #573142 uses some ugly hacks which are temporary until the gio methods can be changed - however it makes no sens of creation my own merge branch as it would cause problems later [not matching ids etc.])?

This is now landed on master.