Jorge Luis Zapata Muga schrieb: > > Having a common agreement isnt easy but we should make one. Cedric > ideas of providing a common API and just do some macros is useful, i > agree that the structure of the code using might have to change, but > either way a list API of any kind, is more or less common, you iterate > over it with the next and prev and you get data, the rest is an > extended API. A big effort has to be made from us to port everything > on cvs to it, but one time or another this has to be done. >
I don't think that an unification of the list APIs is possible. And even if, we'd end up to change thousands of lines of stable code, which was tested over many years. And that without any reasonable benefit. >> Iirc, there are some things in eina that raster didn't want to have in >> the data type. I haven't looked into eina lately, but last time i did he >> > > Well, having some subsystems of eina not desirable isnt an excuse to > have 5 implementations of the same ;) > We have two string pools and the lib I proposed would reduce it to one implementation. > > If stringshare pool already has a common API between ecore an evas > ones, why not put that on the current effort of a common data type? > I'm not sure if I understand you correct, but that's exactly what edt was meant for. > eina should be included into cvs, im ok with that, im kind of > restrictive to indentation changes, but that's another matter :) > > In my opinion the first thing that should be done is add the svn code > into cvs, then add your stringshare there and slowly port the rest, > eet is a special case because it already has a release, so it should > depend on another releasable code (eina) which isnt complete, so eet > might have to be last one to be ported. > 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 think that a good thing to do is to actually compare both API's and > try (if possible) to merge them, any volunteer? for the simplest use > cases of course, get a data from the list and iterate over it. > I don't like the two very much, but I believe we have to keep both implementations. As I said above, I don't think it is worth the effort. And about merging them, you haven't much space for that, because eet expects a evas_list-like API. ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
