On Wed, 1 May 2013 21:13:37 +0900 Cedric BAIL <cedric.b...@free.fr> said:
> On Wed, May 1, 2013 at 6:38 PM, Tom Hacohen <tom.haco...@samsung.com> wrote: > > It recently came to my attention (a week ago) that JackDanielZ is > > writing a JSON parser to go into the EFL. > > I've been arguing against it on IRC, but I think it's time to post it here. > > > > Although most of us (some more than others) suffer from a severe case of > > NIH, I think this is really going one step too far. > > > > Sure, a JSON parser is easy to implement and is sub 1000 lines of codes. > > That on it's own is not a good enough reason to get it in. > > We already have enough code to maintain. We always complain that we > > don't have enough people to do X and Y. The reason for that is we insist > > or adding more code we need to maintain instead of using one of the many > > available solutions. > > > > There are: > > json-c, yajl and jansson to name a few. > > > > It's crazy to re-implement it. We'll have to test it on our own, > > maintain it, document it, debug it and other kinds of unwanted extra work. > > So you are arguing that linking to a library of 1000 lines is better. > And witch one to choose. Let take the fastest one in fact, QT Json > implementation is the fastest one by an order of magnitude. So if I > start an EFL application and I want the fastest JSON implementation, I > am better using QT... Sounds like a very good idea to me. > > Also all implementation have draw back, first all of them come with > their own hash implementation, their own list implementation and all > of them do not integrate with our own code. So you can convert the > result to Eina_Value by yourself from a cjson object or any other > implementation, remember they are 10 times slower than the Qt one, and > now you even do a convertion adding insult to injury. It is just a non > competitive and viable solution. > > Oh, and it is so difficult and dramatic to write a JSON parser that we > already have one implemented in an Everything module and nobody did > complain about it. Why ? Because the standard is simple, once > implemented their is no maintenance their. We need just a properly > implemented one that does integrate with our code and is as fast as > the Qt implementation. Oh, and we already have the Qt benchmark to > start with, so not as if we will push something slower or non > competitive. > > And apparently people are using JSON quite a lot those day, not > providing a proper and viable solution is not going to help us at all > here. But sure we can recommend people to link to the fastest > implementation... i will say.. it depends on the parser. if its sax-like then it doesnt expose/fill in any data structs etc. but if it is exposing hashes, lists etc. then the usefulness of a non-efl parser becomes exceedingly low as we now invest 1k lines of code in converting/transporting data back and forth anyway. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
