On Fri, Sep 23, 2016 at 06:59:14PM -0700, Cedric BAIL wrote: > On Thu, Sep 22, 2016 at 4:35 AM, Tom Hacohen <t...@osg.samsung.com> wrote: > > On 22/09/16 00:34, Cedric BAIL wrote: > >> On Wed, Sep 21, 2016 at 1:46 AM, Tom Hacohen <t...@osg.samsung.com> wrote: > >>> On 19/09/16 23:33, Cedric BAIL 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. > >>> > >>> 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 ?
For the same reason as why there are different log domains, if i have a issue with eo ref stuff, i would not like to get the complete output of ecore/eina. > > <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. > > > 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 ! > > >>> 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. > -- > 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
