On Wed, 1 May 2013 10:43:39 +0100 Michael Blumenkrantz <michael.blumenkra...@gmail.com> wrote:
> I argued vehemently against having an xml parser in eina, and the same > principle applies here. Too bad I seem to always be on the losing > side of these types of decisions. /me pushes Mike to the pro JSON side, so it looses. > On Wed, May 1, 2013 at 10:38 AM, Tom Hacohen > <tom.haco...@samsung.com>wrote: > > > Hey guys, > > > > 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. > > > > Together we can stop this madness. Just send "NOMOREDUP" to 1212 to > > donate £5 to the effort. Hm... I meant, just reply to this email and > > voice your opinion. No more useless code duplication. If I remember correctly, not that I've actually tried it yet, eet was supposed to be usable as a wire protocol. JSON is yet another wire protocol, so it's a duplication of features that we don't need. In another project I have a user wanting a JSON interface. I said fine, write one yourself, as a stand alone binary that wraps around the more efficient real wire protocol. If you want that sort of bloat, you put up with it yourself, keep it out of every one elses faces. After all, people that like bloaty shit should not mind it being a little more bloaty, and the rest of us can avoid it entirely. So JackDanielZ could write his JSON parser as a stand alone wrapper around eet, but keep it out of EFL, and every one is happy. In this way, people have more choice, those that want to actually use JSON can, those that don't can use the more efficient protocol directly, and as a bonus, compatibility in all apps between the two protocols. Then he can make Mike even happier, by rewriting the EFL XML parser as a layer around file based eet, and moving that to a separate binary as well. After all, he would by then have plenty of experience in wrapping eet with bloat. B-) -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
