It's less about actual size and more about not creating another ecore :P -- Tom.
On Mon, 2011-02-28 at 10:58 +0100, Cedric BAIL wrote: > Hi, > > On Mon, Feb 28, 2011 at 10:24 AM, Tom Hacohen > <tom.haco...@partner.samsung.com> wrote: > > On Mon, 2011-02-28 at 10:02 +0100, Michael Blumenkrantz wrote: > >> Shouldn't this go into another lib? Eina's api is already huge, adding an > >> xml > >> parser seems to be taking it into GLib territory... > > > > I'm not 100% sure about it, but I tend to agree. > > I do think it could end in Eina as long as it stay simple, fast and > clean as it is right now ! Eina does mean tool, we do need a xml > parser and it's a tool. So it does fit it in nicely. > > It doesn't increase size of Eina that much, as the code is less than > 1500 lines (including comments). It also doesn't include any > dependencies and doesn't allocate memory (statically or on the heap). > > All in all, I do think it should end in Eina. > > Speaking about Eina size, the three biggest offender are in size > order: Fixed Point, Tiler and QuadTree. Maybe we should focus a little > on reducing the impact of this piece of code... ------------------------------------------------------------------------------ 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
