On Mon, Nov 3, 2008 at 9:05 AM, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > On Wed, 8 Oct 2008 16:12:13 +0200 "Cedric BAIL" <[EMAIL PROTECTED]> babbled: >> On Wed, Oct 8, 2008 at 4:02 PM, Gustavo Sverzut Barbieri >> <[EMAIL PROTECTED]> wrote: >> > On Wed, Oct 8, 2008 at 10:19 AM, Cedric BAIL <[EMAIL PROTECTED]> wrote: >> >> On Wed, Oct 8, 2008 at 3:00 PM, Viktor Kojouharov <[EMAIL PROTECTED]> >> >> wrote: >> >>> On Wed, 2008-10-08 at 14:46 +0200, Cedric BAIL wrote: >> >>>> Hi, >> >>>> >> >>>> As it seems like a good time to break the EFL agains :-). I would >> >>>> like to discuss API/ABI break of eet. I am currently working on adding >> >>>> crypto to eet. My current code only require a key and generate the >> >>>> needed salt and IV for the encryption. So I need to add one more >> >>>> parameter (the key) to all read and write operation of eet. I have >> >>>> currently two possibilities, double the number of function, or just >> >>>> change the existing one. Of course the later solution sounds a little >> >>>> bit cleaner, but it will break all eet applications. >> >>>> >> >>>> A quick search of eet_open in the svn give me 43 differents file >> >>>> using it. Sounds like not a big deal to break it. This could be also >> >>>> be a good time to cleanup the parameters of >> >>>> eet_data_descriptor_element_add also. >> >>>> >> >>>> So guys, what do you think of this move ? >> >>> >> >>> Wasn't eet 1.0 released a couple of weeks ago? Breaking the API after >> >>> the supposed stable 1.0 release just screams wrong in so many ways. >> >> >> >> Yeah, I know, that's why I asked. I just don't like the idea of not >> >> breaking the API/ABI and adding code to work around for marketing >> >> issue. >> >> >> >> Just looking at the TODO. We are planning to add : >> >> - support for scripting langage to convert from their object type to >> >> eet data and from eet data to script object. >> >> - streaming API for both audio and video. >> >> >> >> The only draw back on switching to 2.0 branch on Eet, is that we >> >> currently have one standing bug covered by the test case, that I can >> >> find a way to fix (bug in dump/undump) and this will mean that at some >> >> point we will need to make another release of the 1.0 branch. >> > >> > Do we need a different key for each read/write operation? I see this >> > being more a key per file, in that case make an eet_key_set(ef, key) >> > and check for the set pointer inside read/write operations. >> > >> > the existing parameters are really one per entry, like compression. >> >> I am not really planning to cypher all the data of the file, but just >> on a entry basis. So you can cypher eet data, but not picture for >> example. And I want to add this to eet_data_descriptor_decode and >> encode too. >> >> Between it will be a good time to also remove eet_data_descriptor2_new >> and eet_data_descriptor3_new.
> hmm an api break... hmmm. hmmm. very soon after a 1.0.0 (i knew it was too > soon!). > ok - here's my deal. remove descriptor2/3 and merge that all into 1 so fix > that > mess and you get your cypher key - as long as it doesnt break apps (eet using > apps and libs) :) > maybe you want to postpone this until all the eina stuff is done? I need crypto support soon, so I will provide a patch that doesn't break API. Before breaking eet API, I agree that we should first finish this move to eina, currently postponed for around 2 weeks as I have some deadline. But I have a little bad news, we will need more than just breaking eet API. There are currently 2 bugs regarding eet dump/undump function, one that I almost know how to solve and another one that I don't understand yet what is going on. The first one is just the dump/undump part of list/array/hash of strings bug. The problem is in that case that we loose the information in the eet data that the chunk is an item part of a list/array/hash and not only a string. Solving it is easy... we just need to change eet data format so we always store simple type and the group type. I think we can make it backward compatible, by just handling both current and new format with a new magic string. I have just starting to work on a fix, but it's not high enough on my TODO list at the moment. So don't expect complete fix before a few weeks. The second bug is due to undumping struct of struct which doesn't result in the same eet data as the dumped one. My guess is that this bug is related to EET_G_UNKNOWN case in _eet_data_dump_encode. But I wasn't able to find a fix nor really understand what is going on in that case. So eet TODO list is quite nice at the moment and need a little bit of work before any major release :-) -- Cedric BAIL ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
