path: root/src/lib/emile/Emile.h (follow)
AgeCommit message (Collapse)Author
2016-03-28Emile: Move colorspaces to Efl.GfxJean-Philippe Andre
A small hack to the toolchain allows us to generate enums with eolian for use by Eet and Emile (internal or otherwise non-eo libraries). Thanks to how BUILT_SOURCES works, the eo.h files required by Emile will be generated before they are used. This adds a partial dependency on eo for eet and emile: - package dependency - include dependency There is no library link dependency.
2016-01-07emile: move all eina_str_base64 to emile_base64.Cedric BAIL
2015-05-07emile: remove the need to order the header correctly for Windows.Cedric BAIL
2015-03-17emile: cleanup header from useless cruft.Cedric BAIL
2015-03-17emile: normalize compression header.Cedric BAIL
2015-03-17emile: normalize version number to 1.14.Cedric BAIL
2015-03-17emile: update documentation version.Cedric BAIL
2015-03-17emile: split headers.Cedric BAIL
2015-03-17emile: remove use of custom structure and prefer Eina_Rectangle.Cedric BAIL
Get rid of warning inside of the jpeg loader that result of it. I do believe this is not an ABI break on the loader API. If you disagree, please raise your voice.
2015-03-17emile: initial addition of emile image support.Cedric BAIL
2015-03-17emile: Add SSL support.Cedric BAIL
2015-03-17emile: make cipher initialization optional.Cedric BAIL
2015-03-17emile: add compress/uncompress logic.Cedric BAIL
2015-03-17emile: expose cipher/uncipher block logic.Cedric BAIL
2015-03-17emile: initial introduction of Emile.Cedric BAIL
The intent of Emile is to be the common layer for serialisation, compression and ciphering. It will expose the library we currently use internally to an easier use from the outside (like gcrypt and lz4). It should improve portability. Instead of pushing JSON, XML and what's not to Eina, I do think that they will fit better in Emile. As for the naming of Emile, you will need to be French and say : "Un quoi ?" "Un serializer !" Regarding why it is put there in the stack. Right now there is two users of compression (eet and terminology), two users of cipher library (eet and ecore_con) and a few handful of user for serialization (eina, eet, efreet, ecore_con, ...). So the choice was quite simple, it needed to be below Eet. Now it could have been on top of Eo or integrated into Eina. One of the use case I am thinking of, is to compress Eo object when a canvas get hidden/minized. For that it require Eo to use that library and it can't be a higher level object. And with current implementation of Eo it is perfectly possible to implement such idea. So not at Eo level. As for Eina, I am starting to think it is getting to much things in its namespace. I do believe that infact Eina_Simple_XML and Eina_File should after all have landed in their own library. That's why I am putting the current logic in a new library. It is going to expand, I want it to provide an few SAX like parser for JSON, Eet_Data and protobuf with also an API like Eet_Data to directly feed those value into a C structure without using a DOM at all. It would also be the right place to experiment and benchmark for a new Eet_Data format that could be more efficient to use. So at the end, and due to how I see things going and being used, I do think it is better of in its own library.