Emile: Enlightenment EFL's Latest Addition

[phoronix]

Phoronix: Emile: Enlightenment EFL's Latest Addition

A Samsung developer has landed the latest addition to the Enlightenment Foundation Libraries (EFL): Emile...

http://www.phoronix.com/scan.php?page=news_item&px=Enlightenment-Emile-Announced

[uid313]

Bad idea?

Serializing, compression and cryptography have nothing in common.
These should be handled separately.

Mangling them all in one will probably lead to cryptography with weaknesses, poor compression and slow serialization.
Not to mention the undesired overhead when you only wish to deal with one of the three components.

Also, instead if putting it under the confusing umbrella Emile which says nothing, just logically structure them up in namespaces instead.
Such as;

• Enlightenment.Compression
• Enlightenment.Cryptography
• Enlightenment.Serialization

[Zplay]

Finally I understood the pun with Emile and the serializer !

There is a french movie (la cit? de la peur) in which 2 people speak about a "serial killer" pronounced veryyy bad, and later you understand that the killer is Emile ! You need to watch the movie to understand...

[Daktyl198]

Serializing, compression and cryptography have nothing in common.
These should be handled separately.

Mangling them all in one will probably lead to cryptography with weaknesses, poor compression and slow serialization.
Not to mention the undesired overhead when you only wish to deal with one of the three components.

From what I got out of it, this is merely a layer on top of their already-used backend(s) to make the API simpler and easier to work with. Sort of like Photon for KDE, but not for media stuff.
In that way, ofc it's going to produce a tiny bit of overhead, but not as much as you're thinking.

[raster]

Serializing, compression and cryptography have nothing in common.
These should be handled separately.

Mangling them all in one will probably lead to cryptography with weaknesses, poor compression and slow serialization.
Not to mention the undesired overhead when you only wish to deal with one of the three components.[/LIST]

Actually it wont implement the code - it's more as a simplifaction/switching layer. E.g. openssl vs gnutls. Some people are religious about which to use - we don't want to have #ifdefs through out code wherever it is used, so centralizing it in one place makes sense. (we already end up supporting both openssl and gnutls). compression-wise we have ended up distributing the lz4 and zl4hc code as well as using libc's gzip handling, and abstracting this with a simple "here is some data, compress/decompress it using method X" simplifies a decent chunk of our code and avoids duplications. It's just removing multiple copies of the lz4/lz4hc etc code. As EFL as a library set uses both of these things, the cost is already there (in terms of it being in the codebase and thus binaries that are compiled). They are standard features we have, and this cuts down the cost by only having one set of driving code for these, instead of 2 or more.

Also, instead if putting it under the confusing umbrella Emile which says nothing, just logically structure them up in namespaces instead.
Such as;

• Enlightenment.Compression
• Enlightenment.Cryptography
• Enlightenment.Serialization

Well last I heard about it, Emile was meant to be a low-level "internal" API. We would have a higher level object API on top for "public use", with compression objects and maybe streaming APIs that are likely glued into the mainloop and thus these transforms would happen in background threads, so the caller doesn't need to deal with that themselves (just point to bit of data, have callback called when data is compressed/encrypted. We make the API "public" because our libs have to interface to each other thus have to expose an API one way or another.

I hope that clears things up a bit.

[TumultuousUnicorn]

Why not, I'm curious about Enlightenment improvements.

Finally I understood the pun with Emile and the serializer !

There is a french movie (la cit? de la peur) in which 2 people speak about a "serial killer" pronounced veryyy bad, and later you understand that the killer is Emile ! You need to watch the movie to understand...

Quel mauvais jeu de mots.