On Wed, 1 May 2013 20:12:25 +1000 David Seikel <onef...@gmail.com> wrote:
> 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-) I forgot to mention, we already have a precedent for this - the edje compiler is a wrapper around a bloated human language that produces nice efficient eet binaries. -- 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
