On Fri, Jul 11, 2008 at 11:11 AM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: > Cedric BAIL schrieb: >>>> Putting eina now into cvs doesn't help anyone at the moment. There are >>>> two ways we can go: >>>> >>>> 1. First we start with a little lib, where we put step by step code into >>>> it, >>>> we agree with that it belongs into the common lib. That's what I tried >>>> with edt. >>>> 2. We first discuss how the common lib needs to be en bloc and in detail >>>> and >>>> then change eina to match the result of the discussion. And move it then >>>> into cvs. >>>> >>>> It looks like most people here prefer the second way.
>> I will say we have a third option. Put a common lib in cvs now. Then >> slowly move stuff around to the new system. With current work from >> caro with Evas_Data.h we should be able to provide a set of macro that >> will help do the move quickly. This move should not impact performance >> at all (and looking at eina current code, I don't see how it could >> change something regarding that). > With focus on evas this is right, but you would be going to make facts > without discussing them before. I think we didn't understand together. When I say slowly move stuff around, it include changing and improving Eina to fit our needs also. Eina is not a finished library, but an ongoing development. It's just a good starting point imho to get stuff done faster. > For example in eina the evas_hash implementation is called eina_hash. I think > it'd be better to reserve this name for the ecore_hash implementation, because > it is much more general. For the evas_hash implementation another name like > eina_strhash would imho then be better. I agree with your rename it make sense. But I still think that doing this review with the code in CVS would be faster. Instead of just discussing we will have code progressing at the same time and every one following development on the CVS will be able to participate in this review and get stuff done faster. > And I'm still not convinced if there is a general need to have a > fixed-point implementation in the base data types lib, just to mention my > concerns. Maybe someone else, with more authority then me :), will join this > discussion. In my opinion, it's easier to remove code than to write :-) I don't see any direct user for this feature right now, but with the planned evolution of evas, their could be some. So I d > I'm sure turran took care in doing eina, but you'll get more agreement if > things are discussed before. The idea of moving eina inside the efl librarry CVS repository is to take care of it as a group and use this as a fast starter. It's a lot of work to move data type out of Evas, preserving speed, feature and stability. So that what we win by using eina as a starting point. Then as a group we can change and update this stuff according to our need. I am sure Turran will agree on this. -- 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
