On 05/01/2013 04:02 PM, Tom Hacohen wrote: > On 01/05/13 13:13, Cedric BAIL wrote: >> 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... > You have said it yourself, you haven't given cJSON a try, you don't know > if it's indeed slow than the Qt implementation. > > The only reason no one has noticed and commented about the one in > Everything is that no one ever looked at that code. Had I noticed, I > would have commented about it before. > > Mike can interject, as he has used cJSON before, and I don't remember > him mentioning any issues. > > > Your main argument is the speed, though I have requested benchmarks and > comparisons with eina_json yet I have seen none. If it's so simple to > implement, how come there are so many implementations? How come they > vary in speed so much? And where do we stand compared to others? Tom, you know that the reason why we didn't provide benchmarks yet is that because we have feature requests from HQ. Sure, we will check the perfs.
Concerning the JSON parser itself, except the benchmarks comparison + minor finalization, it is ready. So it just depends on the "vote" and really, the decision doesn't matter to me. I hate being between the EFL old couple (i.e Tom and Cedric). Well, maybe I like that. I will create a branch for that soon so you will be able to look and complain. > > -- > Tom. > > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
