2016-08-05 18:53 GMT+02:00 Cedric BAIL <cedric.b...@free.fr>:
> 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 ?
>
Cedric I really cannot understand your point here (as I didn't in the
promise discussion). If something goes wrong inside the constructor
then eo_add() should return NULL and the user must take care of it.
Are you thinking at some threaded scenario? like something
can happen between the eo_add() and the callback_add() calls?
Otherwise I cannot see how the gustavo example (with NULL
check added) can be wrong.
>
> > 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.
>
> > - 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.
>
> > - 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
>
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
