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... -- Cedric BAIL ------------------------------------------------------------------------------ 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
