On Thu, 15 Oct 2015 08:48:04 +0200 Cedric BAIL <[email protected]> wrote:
> The bigger question here is what do you want to put into those 32MB ? > 32MB was the configuration I had with Elixir a few years back. That > was enough for running a full JS VM, but not for a desktop. I am > pretty sure at 32MB, you do one application (a JS VM, a Lua VM, > whatever VM), but not really a real multitask environment. In which > case, the strategy of reducing the number of write page for eo doesn't > pay as much, or is maybe even counter productive. Or are we trying to > target doing a multitask environment in that budget ? If so, then the > challenge is way higher than just tracking our 200Kb of wasted memory. > We have to put some serious though on how to do so and start chasing > every little bit of duplicated memory, even find how to do so accross > process. That's a huge challenge. To be honest, my embedded device has way more than 32 MB, but it is what you state, a single application, no desktop, no "real" multitasking. On the other hand, it doesn't need all the RAM it has, could use much less, just that the embedded board my client settled on has way more than 32 MB. They don't make a smaller version. > > lib... > > > > efl, eina, eo, emile, eet, ecore, eio > > -> efl > > > > ecore_input, ecore_input, ecore_audio, elocation, ecore_con, > > ecore_ipc, ecore_imf, efreet, efreet_trash, efreet_mime, eldbus, > > ecore_file -> efl_sys > > Here, I am on the same opinion as mike. Efl_Network make a lot of > sense. This means we can actually get a headless configuration of Efl > for network task only. Otherwise Efl is never going to be really > useful in a network context. For extending the user base, I think > spliting this is better. Headless EFL would be useful to my virtual world project, since some of that is server side. Currently it has a world server, and a script server (I'm aiming for Second Life / OpenSim compatibility, so it supports the LSL scripts that Second Life invented). The client connects to the world server, the world server connects to one or more script servers. The servers have no UI of their own. I intend to add a physics server as well. Both servers and the client are written using EFL, the physics server would be as well. The servers can pass UI requests to the client. For example the llDialog() call in LSL runs in the script server, but it's job is to pop up a dialogue on the client, which then returns the users input to the script. So network transparency for UI stuff is part of what I'm working on here. In the example given, the UI passes through two servers to get to the client. > > eeze > > -> stay for now (be replaced with a high level device abstraction > > that doesn't look like or depend on linux sysfs at all) > > > > elementary > > -> stay > > I would say, stay for now, but on the long term we want a cleaner > Efl_Widget infrastructure that rely more on Efl_Model and Eolian > properly (With also less useless widget and more run time widget > infrastructure, aka project Bob). I mentioned the old Java UI / widget project in my last post on this thread. I think we agree on this. Mine will be a modular widget system, my theory being that complex widgets can be made from a few generic widgets. So less useless widgets, if you want them build your own out of the modular parts, and more run time widget infrastructure, you can build your complex widget at run time. > Also I think that we do still have a user base that needs some good > configuration of our code base. Onefang being just one example of > them, clearly the most vocal one on this ML. As far as I know the > other are more silent and stopped using recent EFL sticking to 1.7. See Raster, it's not just me. :-P > I would prefer here to be more inclusive and I don't think there is > any real cost into supporting those configuration #ifdef as they are > already needed for portability reason. Ecore_Wayland. Ecore_X. > Ecore_IMF on Windows ? Not really. > > So again here, we can get Jenkins to build a very minimalist version > of EFL and continuously check it. The cost of maintenance should stay > low if not make our live easier for portability (Windows, MacOS. > Android, ...). Now what we need is to define what this minimal > configuration should be and put that into Jenkins. Reminds me that last time we had a similar discussion, the concept of "profiles" was mentioned. I think "headless", and "embedded" might be two good profiles, as well as "desktop". In the case of this "minimal" profile you mention, some way to add on specific extra parts for those that require "minimal+" might be good. Which basically brings us back to --disable-* / --enable-*, as it was in the EFL 1.7 that Cedric mentions people sticking with. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
