On Sat, 24 Sep 2016 11:07:16 +0200 marcel-hollerb...@t-online.de said: > 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.
a problem solvable with ... log domains :) > > > > <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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
