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? -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
