Re: [E-devel] EFL interface, what's left to be done

[Carsten H. (T. R. <ra...@ra...>]

On Fri, 23 Sep 2016 18:59:14 -0700 Cedric BAIL <ced...@fr...> said:

> On Thu, Sep 22, 2016 at 4:35 AM, Tom Hacohen <to...@os...> wrote:
> > On 22/09/16 00:34, Cedric BAIL wrote:
> >> On Wed, Sep 21, 2016 at 1:46 AM, Tom Hacohen <to...@os...> wrote:
> >>> On 19/09/16 23:33, Cedric BAIL wrote:
> >>>> On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen <to...@st...> 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.
> >>>
> >>> Sorry, I missed that thread. What was the topic?
> >>
> >> Merging eo, efl and ecore. Like in the title :-)
> >
> > I remember that thread now, I misunderstood what you meant by merging
> > when you said it back then, and now with your promise inside lib/eo/ I
> > understand what you meant, and I'm very much against it.
> >
> > Let me clarify what I mean compared to my understanding of what you
> > mean. What I mean is what I thought was discussed in that thread.
> > I'm fine with:
> > Linking everything into one big fat ugly libefl.so (would rather not,
> > but OKish with that).
> > Having Efl.h that includes Eo.h, Elementary.h and etc.
> > Having an efl_init() and an efl_shutdown() that call them all.
> 
> With EFL_MAIN, you don't need anymore to do any _init/_shutdown. Just
> for reference.
> 
> > But if you think about it, it's essentially what we have in elementary.
> > It does all of the above except for the one binary linked together.
> > Which I'm mostly OK with (although see Marcel's comment about eo_debug
> > about which I forgot. Modularity has many advantages).
> >
> > What I'm *not* OK with:
> > Creating interdependency between the libraries and essentially making
> > libefl.so Ecore 2.0. One place to store everything. Units make a lot of
> > sense, of the advantages have been discussed above. My eo_debug trick
> > (which is ready, I just need to enable it, again, see marcel's email for
> > details) requires this separation.
> 
> Saw it, it's neat. Question, why limitting it to eo ? Would be quite
> useful to also turn on more debug in eina, no ?

a combined libefl.so (that is eina+ecore+eo+efl) wouldnt stop this - build 2
libefl's and use LD_PRELOAD to switch. same exact thing. just the debug lib is
bigger with more unaffected code. in fact what cedric says makes sense as we
can expand debug to eina and the mainloop and more.

> <snip>
> 
> >>> Or without joking: people have been using Eo without ecore and without
> >>> Efl.Object. One example is Mike in E (reverted now because Eo was
> >>> undeclared stable). You'll probably end up using Ecore in the same app,
> >>> but again, everything you can say here you can say about Eina too.
> >>
> >> Do we have any example of an application that use Eo without Ecore or
> >> Efl today ?
> >
> > edje_cc, expedite, erigo-cli, clouseau-launcher (not the gui) and etc,
> > all depend on Eo and not on graphics. As for Ecore: I'm actually not
> > sure, some probably use ecore for networking, but it doesn't matter,
> > that's just a convenience that happened to be relevant for this case.
> > Sort of: if you can afford to use something that makes your life a bit
> > easier, why not.
> 
> All of the above example do use ecore and where kind of my point.
> 
> >>> By "clean" I mean "isolated" or "untainted by its users up the stack".
> >>> (see next comment for more info).
> >>>
> >>>> 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 ?
> >>>
> >>> That is exactly the reason (was I hiding it?), but not only, and one
> >>> example of not "clean".
> >>>
> >>> A while back I was giving you some flack for not writing tests for a
> >>> component of the EFL and cited Eo as an example of getting high test
> >>> coverage. You then laughed it off and said something in the lines of
> >>> "it's easier to test because it's smaller and not async" or something
> >>> like that.
> >>> **THAT IS EXACTLY MY POINT.**
> >>>  From my experience (and I guess the industry's collective experience),
> >>> having small separate units make quality assurance easier, units more
> >>> testable (because you can easily unit test) and the code easier to
> >>> maintain.
> >>
> >> In my opinion there is a lot of code in Eo that is far from nice to
> >> read and easy to maintain. First example is how intricate our pointer
> >> infrastructure is in eo and how little it makes sense. I have to go
> >> back at eina_safepointer, but there is seriously no justification for
> >> that. Especially when it hasn't help us catch thread safety bugs for
> >> example. So I agree with your small unit, but small unit has nothing
> >> todo as per library, it has to do with how we divide things between
> >> functions and files.
> >
> > No, it has everything to do with interconnectivity of components. Small
> > units mean: interdependency is allowed within that unit but not outside
> > of it.
> 
> I don't see your problem at all. We have a lot of "independent" unit
> tested properly in eina and eet. Would you have preferred to see eina
> split for each data type ?
> 
> > Safepointer: that's a different topic. Maybe it belongs there. I'm not
> > sure. However, that's migrating things out of Eo and making it smaller,
> > which I'm happy with. :)
> 
> Ok.

i think we should drop einasafepointer. its duplicating what's in eo and eoid.
in fact it will now have bugs vs eoid. :) eoid is just more solid/better.
keep it there. :) dont put this in eina

> > As for your case, ptr indirection is implemented in different source
> > files and has no interdependency, so it can be easily pulled out
> > whenever needed.
> 
> It doesn't have any clean API and there are ifdef all over the place
> in eo to handle it. Tearing it appart isn't trivial...
> 
> > OK, so Eo is less than perfect ergo we should make it worse? I don't see
> > your point. Yes, Eo has been made a bit uglier in the last few months.
> > It actually made it hard for me to keep track, but it sometimes happens
> > when you have a lot of contributions from various sources. However
> > because of its isolation, it remains well tested.
> 
> My point is not that it isn't perfect, but that it is not an isolated
> piece and that the issue is with unit that don't have a clear API.
> Once you put an API, which moving stuff to eina force us to in that
> example, you get the clean unit you want.
> 
> <snip>
> 
> >>>>> If you mean just compile them together, then there's no point in it.
> >>>>> I know why you want to do it, you want to do it because you put
> >>>>> Efl.Future inside libeo.so, but the correct thing to do is probably not
> >>>>> to put it there.
> >>>>
> >>>> 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.
> >>>
> >>> Of course also merging the headers. What I meant is: you want a cycle
> >>> dep. Mutual reliance.
> >>
> >> They need it. efl_future_link is the perfect example. How can you link
> >> the life time of a future to the one of an object without having that
> >> function in efl.object, where it belong.
> >
> > Have a mixin/interface that implements the relevant interface for
> > objects that are loop aware (and thus can use promises). This is how it
> > should have been done, not sure what you are doing now.
> 
> Well, what you mean here, is that we will have an Efl.Object_Loop that
> every single object in Efl will inherit from. Every single one of
> them. Just to implement one function !

they just have to inherit the INTERFACE :) i kind of agree with you that we we
have a cyclic dep. loops and objects. they are very closely tied for us and
thats just how it is. fighting it is fighting the sun coming up in the morning.
pointless :) i made the mistake of trying to make evas "loop independed". that
was wrong. and i think given promises and trying to do so much async that
having loops as a core concept for efl is important. in fact the whole eoid tls
thing kind of leaks in threading and loops too as there is a MAIN domain then
a thread one and a shared and "other" and so its assuming other threads. with
no nice clean eo way of making threads this kind of feels odd. merging in loops
makes it very clear how all of this comes together.

> >>> It's not really a broadcast, because you need to register to listen.
> >>
> >> It is a broadcast. My computer receive all broadcasted packet on my
> >> network all the time, the same as an object will always receive events
> >> even if nobody is listening to it. Some, like animator, are
> >> implemented like multicast, where you have to actually register an
> >> event to get the signal propagated to the object.
> >
> > Object will always receive events: you mean callback_call? That's some
> > definition of receiving events. The event is never really "emitted" if
> > no callback is registered. That's arguing about bullshit lingo though.
> > Events are not called. I have no idea what you are talking about.
> 
> The callback_call is emitted. The event structure is build, the
> function is called and it walk the list of registered callback to see
> if there is one that match. This is very close to what a broadcast
> packet on the network does. It reach the system of every computer
> connected to the network, the packet goes up the stack and the OS
> check if any process is listening for it. How different is it ? It is
> a broadcast.
> 
> And for multicast, it is just propagated along a tree if some of the
> leaf have registered a server there. How different is that from the
> behavior of our animator event ?
> 
> >>> Removing events from Eo is not the way to go. If you want an async
> >>> pattern, do it up the stack (even eolian) and encourage it there. People
> >>> who use the loop will use it. The same way people use Evas when they
> >>> want it (not trying to make a funny comment, literally, people include
> >>> Evas.h when they want to use it).
> >>>
> >>> Quite a similar example that reveals better what I mean and see:
> >>>
> >>> Let's assume we have a TCP class. You want to add HTTP support to the
> >>> EFL so you are adding an HTTP class that inherits from it. Now your
> >>> argument is that you want to merge them because you want to encourage
> >>> people to use HTTP and not roll their own protocol and arguing that if
> >>> not that so at least move the port_set (events) function somewhere else.
> >>
> >> Thanks for the example. You need TCP to build HTTP. If there wasn't
> >> TCP in the IP stack, you would reimplement it in every protocol up the
> >> stack on top of UDP. Would not be fun at all. FTP, SSH, HTTP over UDP
> >> ? With all the fun of trying to reinvent the session thing. My
> >> argument stand that you want to have a async request mecanism in efl,
> >> because you want all this protocol on top to rely cleanly on it and
> >> not reinvent a bad interface or make mistake.
> >
> > Huh? I don't understand your example. You need TCP (Eo) to build HTTP,
> > and it's available for you. You are not reimplementing anything. FTP
> > would also inherit from TCP, it doesn't need to know about HTTP.
> 
> Eo is not TCP. Eo is IP. Eo events are UDP (broadcast and multicast in
> nature), while future/promise are asynchronous request with guaranty
> are TCP. How do you think that Eo is able to do asynchronous request
> with guaranty like TCP ??? Just blowing my mind here. I guess,
> choosing network as an image for this discussion is not helping you at
> all.

we will "build tcp" on top. this is likely going to tie in closely with
efl.loop and having threads. thread pools and thread/loop to thread/loop
messaging. i really think we need to figure out for ourselves how threading and
loops come together. i dislike them being separate objects. reality is a thread
and a loop are really one and the same thing. splitting them just creates
complexity not needed. this is a tough discussion that needs to be had.


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...