On Mon, Sep 19, 2016 at 7:33 PM, Cedric BAIL <cedric.b...@free.fr> wrote:
> On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen <t...@stosb.com> wrote:
>> We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty much
>> against it.
> There was a thread weeks ago. You indeed didn't take part of that
> discussion, but everyone else involved in that thread was ok. Actually
> the discussion evolved more into a what else to merge in. So their was
> an agreement before this email.
>> Eo is clean and hasn't been "polluted" by async, mainloop and etc. That's a
>> good thing. This makes our infrastructure easier to test.
> Please define "clean" as it is a bit abstract to me here. What I am
> looking for here is the minimal set of component I need to have
> something useful. Is Eo useful by itself ? With just Efl.Object ? Sure
> you could do C without the C library, but would you ?
> I think that your disagreement about merging is only and just because
> you do not want to make asynchronous request a core feature of EFL.
> The rest is mostly rhetoric. Could you please explain why you have so
> much resistance to it being rolled into more place in efl ?


> I don't want to just compile them together. I want to merge there
> headers. Make it just one library. Make efl.object, efl.future and
> efl.loop one core. Obviously because I want to see efl as providing a
> core asynchronous library with defined pattern. One asynchronous
> pattern is "events", which is like an UDP broadcast (default
> behavior)/multicast (with effort) solution. Efl.Future is more the
> equivalent of a TCP connection. I think providing one without the
> other is going to push for a world of broadcast solution which is not
> always the right pattern. Maybe we should remove events support from
> Eo to avoid this problem.

+10000 fully agree with Cedric's rationale. Eo's purpose should be
solely to serve Efl's use cases, which means asynchronous event driven

promise/future should be first-class citizen... as well as iterator
and the likes. There is a start already, but refinement is really
needed, like returning an iterator<x> should handle warn_unused, free,
own... Promise should have its own callback signature, simplified for
the user.

AND if possible, make eolian or a new tool to handle connections for
us, if it was easy to declare objects with composition of
events/promises, it would save us lots of typing and errors.

Gustavo Sverzut Barbieri
Mobile: +55 (16) 99354-9890

enlightenment-devel mailing list

Reply via email to