On Mon, Feb 28, 2011 at 7:45 AM, Tom Hacohen
<tom.haco...@partner.samsung.com> wrote:
> On Mon, 2011-02-28 at 11:42 +0100, Cedric BAIL wrote:
>> In that case, maybe we should take it from the other side of the
>> problem. What do we plan to add inside eina and if we need to move
>> this infra somewhere else.
>>
>> I do plan to provide an eina_file_mmap implementation that will
>> provide infrastructure for file open/fstat/mmap and cache that some
>> EFL are currently doing locally (Eet, Evas and Efreet come to my mind
>> as the first users of this feature).
>> We also have this XML parser.
>>
>> So what esle could end in Eina ?
>
> If we are adding an XML parser, why not a Json parser as well? And what
> about the 123421 other things there are to parse? If we add them, it'll
> suck, if we don't we'll suck (cause we only support XML in eina, but
> other stuff in other places). Furthermore, I don't want to encourage
> people to use XML, but that's just me :P
>
> My problem is not with specific functions, but with classes of
> functions. Is Eina EFL's config/file/whatever parsing library? If not,
> it shouldn't include it, if so, so yeah, we can add it. One exception is
> if we want to use XML internally for our config and etc, but then we
> should probably not expose the XML api.
I'm suggesting Eina because it's root and at least the SAX-like paser
is almost a tokenizer, much in the lines of the existing eina_str_*
functions.
About JSON, you can't compare. Although both are widely known
web-libs, people managed to put stupid XML into the whole system. From
X kbd mappings to Gconf values.
We could create yet-another library for parsing, like we have Eet we
could have one for XML (libexml?), another for JSON (libejson?)... but
then:
- libraries will be much smaller and will not pay off;
- libraries will be oversimplified and the "will not pay off" tend
to do an impact, why would I link libexml and maybe I'll miss the
features, or I'll link in libxml2 and although big I'll never have to
change, as it's complete (and bloated);
- people tend to add stuff to these lib, that was meant to be
small and simple... soon it will start to get complexities such as
XPath, namespaces.... then we have yet-another-libxml2 that will have
its own sources of bugs.
If you wish you can take out the node serialization thing and put into
another library or throw it out, leave as an example somewhere in
svn/wiki. But the basic should remain in Eina, we have potential
users:
- efreet;
- azy (at least for it's source files);
- e17 language/xkbd modules;
- anyone trying to read gconf values from gnome;
- anyone trying to read basic xml returned from web;
Although Eina may look like big, it doesn't pull external libraries
and on my 64bits is about 224kb striped. I guess having lots of libs,
particularly with Linux's dynamic ld-loader, will impose a bigger hit
than this.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
------------------------------------------------------------------------------
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
