Hi, On Sun, Feb 13, 2011 at 4:15 PM, Andrey Riabushenko <cd...@bk.ru> wrote: > I have been looking for ways to make EFL even more compact than it > is currently. One thing I have noticed about eet that it has many > dependencies: > > #ldd libeet.so > linux-vdso.so.1 => (0x00007fff655ff000) > libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0x00007f6b2656b000) > libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0x00007f6b2635b000) > libgcrypt.so.11 => /lib/libgcrypt.so.11 (0x00007f6b260e1000) > libgpg-error.so.0 => /lib/libgpg-error.so.0 (0x00007f6b25ede000) > libeina.so.1 => /usr/lib/libeina.so.1 (0x00007f6b25ca8000) > libz.so.1 => /usr/lib/libz.so.1 (0x00007f6b25a8f000) > libjpeg.so.8 => /usr/lib/libjpeg.so.8 (0x00007f6b25855000) > libm.so.6 => /lib/libm.so.6 (0x00007f6b255d2000) > libpthread.so.0 => /lib/libpthread.so.0 (0x00007f6b253b4000) > libc.so.6 => /lib/libc.so.6 (0x00007f6b25053000) > librt.so.1 => /lib/librt.so.1 (0x00007f6b24e4b000) > libdl.so.2 => /lib/libdl.so.2 (0x00007f6b24c46000) > /lib/ld-linux-x86-64.so.2 (0x00007f6b26a54000) > > Most come from eina, but these are new dependencies: > libgnutls.so.26 (695KB) > libtasn1.so.3 (65KB) > libgcrypt.so.11 (495KB) > libgpg-error.so.0 (13KB) > libz.so.1 (97KB) > libjpeg.so.8 (238KB) > > On my amd64 eet is 109KB library while it is introducing extra 1.6MB > dependency. I see that libz and libjpeg is actively used. However, > eet_*_cipher are not used by other EFL libraries and E17. > > My idea is to push eet_*_cipher to separate eet_cipher library, which > loaded by eet_cipher_init() call. Exactly the same way as ecore is > split. This will allow to reduce the size of dependencies by 80%.
Well, I don't see how you could remove eet cipher and signature functionnality without impacting eet internals. Signature need to manipulate the internal data of the mapped file. That would means exposing this function as a callback in eet_open (if a file is not properly signed, it should not be open at all). As for cipher, you will see that it is used directly inside eet_data.c code. In fact for easier/lighter maintainance we do share code. > I do understand that I can build eet myself with "configure > --disable-gnutls --disable-openssl". But packagers of binary linux > distributions can't do it. > > I don't mind to write such patch myself if the idea will be accepted. Last point I do think we should use more signature and cipher in the futur. Signature for theme and background edje would be a nice feature to be sure that the content you are downloading wasn't altered (Need to be implemented in exchange replacement). As for cipher, some configuration should be stored inside a secure wallet, and the plan is to use eet for that. Even if today we don't use much of eet cipher/signature functionnality (I do use it a lot in elixir JS bindings), it should be more useful in the futur. Last but not least, if you propose such a patch, you should absolutly be API and ABI compatible with 1.0 branch. Meaning it's not possible to add function to enable current feature, you will need to detect when you need them and when you don't. Not that easy at the end to provide something efficient. -- Cedric BAIL ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
