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 :-) >>> 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 ? > > You are right. Let's merge in Eina too. That was kind of the discussion. Argument against merging eina, from myself, is that we do have a lot of tool, just in tree, that do only depends on eina and not on anything else. > 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 ? > 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. >> As for the tests, I really don't like our eo tests. They are not >> really testing a clean scenario that is possible to guess, but just a >> mismatch of everything into one big C file. When something break >> there, you can't just rely on the name of the tests, or reading >> quickly the code to guess what's happening. Nop. You have to get >> hundred of lines of tests with little logical connection to each >> other. I have found them less than useful when developping (And some >> times buggy, as instead of testing a scenario that makes sense, they >> were just testing that the code was matching the tests). So I don't >> get your argument of making it easier to tests. > > The Eo suite is a mixture of success-scenario, failure-scenario and > regression testing. > Success scenario: making sure an expected scenario works. > Failure scenario: making sure an expected scenario fails. > regression testing: making sure what we have stays the same. > > Success scenarios would rarely need changing, only if you change > something drastic or make the code more strict. Failure would need to > change a bit more often, depending on how strict we make the code. > Regression testing will probably change often, as they are there so you > *understand* that you are changing behaviour, even if undocumented. > > I'm not aware of any buggy tests, but do let me know if you find one, > and while at it, if possible, try and fix them. The tests for hot event was completely backward and wrong. Don't worry when I find a bugs I fix it. > You have to also remember, these tests have been with us through a few > Eo rewrites. They have been here from day 1. :) They would benefit from some cleanup for sure and to be closer to an unit tests. >>> 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. > 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. > 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. -- Cedric BAIL ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
