On 05/08/16 04:34, Gustavo Sverzut Barbieri wrote: > Hi all, > > I've pushed my WIP to a branch devs/barbieri/ecore-con-eoify, see: > > https://git.enlightenment.org/core/efl.git/commit/?h=devs/barbieri/ecore-con-eoify&id=35bab5c64a6c928121202697221ecebf4b606659 > > It does compile, but of course doesn't work given the implementation > is mostly stub (and the goal at the moment is only to define the look > & feel of the API). > > As requested by Tom, I've sent an example of usage (just server at the > moment): > > https://git.enlightenment.org/core/efl.git/diff/src/examples/ecore/efl_net_server_tcp.c?h=devs/barbieri/ecore-con-eoify&id=35bab5c64a6c928121202697221ecebf4b606659 > > The client API will be different only to create the socket (using a > "dialer" instead of receiving them from a server event). After the > socket/connection is established, the code is the same. > > Changes since last version: > > - removed Eina.Blob and Eina.Binbuf to avoid side discussions; > > - client was renamed to follow "Go" term: "Dialer". It's a new term > and may avoid confusion (if called "client", is it a client connected > to a server at server side -- as Ecore_Con_Client, or the connecting > peer?) > > - added adopt(fd) to Efl.Net.Socket and Efl.Net.Server, should be > usable when fd was created elsewhere, like systemd or different > libraries. > > - addresses are all strings now. Dialer provides a 'resolved' event. > > - removed the "type" enum, each specific class (ie: > Efl.Net.Socket.TCP) will create the correct fd. There are flags > property to specify whatever else (like: tcp_cork and tcp_nodelay), > which will result in setsockopt(). > > - added close() method and closed event; > > - added timedout event; > > - classes and mixin for real, passes eolian and generates proper code. > > I'm keeping "Efl.Net" to easily separate previous Eo attempt > ("Efl.Network"). We can rename when we're ready. > >
Thanks. The example looks good. It's a bit annoying to have so much boilerplate code to just handle simple send/receive, but I guess that there's no way around it. Why do we need a "sent" event? Shouldn't this just be handled by whoever is calling "send" and then check error code or whatever? -- Tom. ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
