On 29/05/15 17:31, Cedric BAIL wrote: > Hello, > > Srivardhan Hebbar has been working with me on cleaning up and > improving the Eo API exposed by Ecore_Con which will become the future > API of a potential EFL 2.0 (It is also part of the on going work on > redoing all EFL object interface with Eolian/Eo). > > We are at a point where we are satisfied on a small example > Ecore_Con_Url and would like to get some feedback. For people who just > want to just look at the code, a starting point is > https://git.enlightenment.org/core/efl.git/tree/src/lib/ecore_con/efl_network_url.eo > . But a quick explanation may be better for everyone. > > So the idea is to first cleanup the naming. Everything end up in a > meaningful namespace : Efl.Network.Url. Second we solve our long > standing event issue, we now use eo_event, they allow a few benefit > right away. No memory allocation and memory copy are needed to emit an > event and at event registration we can use Eo callback arrays that > seriously reduce memory consumption per object. This two feature > should give us better performance and a lower memory foot print. > > To preserve backward compatibility, if you do create the object with > the old legacy API we register an Eo callbacks array that will emit > the legacy Ecore_Event, making every thing work as it was working > before with no overhead for the Eo direct case. >
Yeah dude, that's the plan. We've been talking about it since the get go. If this all this is about, of course you should go forward. We've already started doing it in ecore_exe (never gotten around to getting rid of the old functions though). As for the namespace: it's also part of the general plan (agreeable or not is a different matter) of changing to the generic interfaces. > A known drawback is that as we do not reschedule reading the data for > later if the main loop is to busy, we could end up having the UI drop > some frame under heavy load (compared to the old system of delayed > event). I have no good plan to address this issue in the short term, > as their is a lot of potential idea to solve this issue. I would > prefer we keep that out of this thread for now. > > Basically the main point of this mail, is are you happy with putting > everything under Efl.Network namespace ? And are you fine with the new > Eo event system ? Are you also fine with the content of > Efl_Network_Url class ? If so we will apply the same change to all > other Ecore_Con API. > Yes, of course. -- Tom. ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
