On Wed, 1 May 2013 14:26:12 +0100 Michael Blumenkrantz <michael.blumenkra...@gmail.com> said:
that makes sense.. but it seems that its already done. as per my comment.. if its exporting eina lists/hashes etc... then it pretty much has to be a newly written json parser as it has to deal with our datatypes. otherwise we just convert from someone elses and that ends up just as much work and we're arguing over a moot point. > 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 > -- ------------- 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
