Hi all,
As you may have noticed (I HOPE!) I was kinda far from EFL development
in the past year or so. The reason is that we were working on some
internal projects and I'm glad to announce that the last project is
finally released as open source!
https://github.com/solettaproject/soletta
While this project has no relation to EFL at the moment, we believe
both projects would benefit from integration and I want your help!
First things first, what is Soletta?
With Soletta Project's libraries developers can easily write
software for devices that control actuators/sensors and
communicate using standard technologies. It enables adding
smartness even on the smallest edge devices. Portable and
scalable, it abstracts details of hardware and OS, enabling
developers to reuse its code and knowledge in different targets
such as Linux, Contiki or RIOT.
Somehow similar to EFL, it provide some basic types and a main loop.
This was required because we're porting it to smaller OS that deliver
events from unsafe ISR and it would be a mess to let high-level
developers deal with that. So we use a main loop to deliver uniform
behavior accross environments, much like EFL developers are used to.
We did not use Ecore as is because we have different goals and
requirements, but we want Ecore to be an implementation alternative.
Currently, for Linux, we offer Glib (because it's everywhere) and pure
poll(2), but to create an Ecore based implementation is pretty simple,
take a look at
https://github.com/solettaproject/soletta/blob/master/src/lib/common/sol-mainloop-impl-glib.c
While the programming language is C, we're pushing for the business
logic to be written in a domain specific language called "Flow Based
Programming - FBP", this way we avoid a common pitfall all EFL
developers are sick and tired of: callbacks and data passing. This
language is not meant to write all the code, rather to integrate parts
and connect flow of information, moving the
"callback_add()/get()/set()" and the validations all to the core, then
we avoid leaks and segfaults.
The idea is that one writes a flow node type (ie: a class) as an
independent black box, with its API being defined only by its ports
and packet types. Then if a black box provides an "OUT" port that
delivers boolean packets, it doesn't matter if this is mapping to a
physical button attached to a GPIO or if it's an elm_toggle or a full
screen that after user interaction results in a true/false response.
To showcase this we offer a module called "gtk" (shame on me, my call,
the reason is simple: gtk is everywhere so one less dependency to
install), but it's very barebones.
THERE is where we see EFL integration shining. Given the power of EFL
and Edje, we could offer common components that do a lot. Imagine a
generic Edje node that offers some basic API, one can implement a
complex interface right there by using Embryo and EXTERNAL. And of
course implement some high level components to be used by people
creating embedded/IoT products with some user interface -- like
Logitech's MyHarmony remote controls or those home automation like
Calaos. We know EFL is the only solution in that space, it's the only
solution to run in such constrained environments.
I know lots of folks here play was makers, doing nice gadgets for
hobby or work (like DaveMDS or Raoul)... so I expect people to share
their experiences and needs so we cover those in the future work.
Last but not least we will also cover much of the embedded/IoT
development problems. Creating a software image is not the easiest
thing in the world, even with Yocto. We also want to provide a
graphical FBP editor so people can see how their nodes connect, etc...
so we need help :-)
--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (19) 99225-2202
Contact: http://www.gustavobarbieri.com.br/contact
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
