On Fri, 5 Aug 2016 09:53:25 -0700 Cedric BAIL <cedric.b...@free.fr> said:
> Hello, > > On Thu, Aug 4, 2016 at 8:34 PM, Gustavo Sverzut Barbieri > <barbi...@gmail.com> wrote: > > 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 > > I think your example does illustrate quite well while asynchronous API > with events is tricky for users to get right. I think you do set your > error handler a little bit to late. What if during finalize the server > is unable to listen to that port for whatever reason ? he should have added the events cb's inside the eo_add() so they are there before finalize. i actually think that the server in this example should still have a connect() but the connect has the server begin listening and this EXPLICIT connect() begins all of thew setup and callbacks will be called here if the socket is in use for example. > > 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; > > I believe this is a mistake (will answer about this to Tom's email to > proove how wronge he is !) and as discussed on IRC most of what you > want to do can be added to Eina_Binbuf. Especially an ability to do > refcounting with a returned buffer that will be a copy on write of its > parent would be really neat in general. i agree - as per my other mail. we can add these things to binbuf. in fact we should see if we can make both strbuf and binbuf work as a lot of protocols are string based it'd make a hell of a lot of sense to support strbuf here.... somehow. > > - 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?) > > Indeed less confusing. > > > - added adopt(fd) to Efl.Net.Socket and Efl.Net.Server, should be > > usable when fd was created elsewhere, like systemd or different > > libraries. > > Hum, I would prefer that to stay internal. Ecore_Con today has a flag > for handling systemd passing, I do prefer that mecanism. agree with you here. > > - 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(). > > Do you plan to have the same for ssl ? > > > - 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. > > Ok. > -- > Cedric BAIL > > ------------------------------------------------------------------------------ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
