On Mon, 2011-02-28 at 11:15 +0100, Cedric BAIL wrote: > I do agree, but the problem of ecore is more because we did add stuff > that have nothing to do with it's primary purpose like Ecore_File API > that is not asynchronous at all and not about event at all (That's not > the only offender of Ecore). > > The fact is that Eina is about synchronous call and providing tools > for the rest of the EFL. So it's the place where all the common > infrastructure will end and with time it's just logical that we will > have more and more common ground for all our library. I don't think we > should split eina any time soon and I do think we should continue to > merge common code in it. But that's just me.
People raised their eyebrows when I first added basic Unicode support... As I said, I'm not 100% sure which is best. All I'm saying is that we shouldn't take this decision lightly, because it'll define the future of Eina (i.e whether we shove future things in, or not). -- Tom. ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
