One of the reasons for not doing this is to not do it; you save those developer resources and put them towards something useful. Saying "I'll have a branch with it implemented soon" completely ignores that.
On Wed, May 1, 2013 at 2:22 PM, daniel.za...@samsung.com < daniel.za...@samsung.com> wrote: > 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 > ------------------------------------------------------------------------------ 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
