Re: [E-devel] JSON parser in Eina - together we can stop the madness
On Thu, 2 May 2013 04:49:27 +0100 Michael Blumenkrantz
said:
> On Thu, May 2, 2013 at 1:04 AM, Carsten Haitzler wrote:
>
> > On Wed, 1 May 2013 14:56:32 +0100 Michael Blumenkrantz
> > said:
> >
> > > cJSON, at least, exposes no hashes, lists, or any of that; I don't know
> > > what crazy parsers you kids have been using which do this, but they
> > > shouldn't since JSON doesn't have any concept of such things.
> >
> > errr.. json is really a tree of string key -> values (where value can be a
> > subtree) so thus by nature its a list and/or hash of strings and/or
> > subtrees
> > make sense.
> >
>
> If you're using JSON for RPC, it doesn't make sense. This is a very common
> use case.
but that is not the point of the json parser jackdaniels etc. are talking
about. it is meant to load and store large blobs of structured data... not much
unlike edc files... so you need to have the view of "general usage where it may
easily be pushed to load large blobs of json of a few mb a pop..."
> > > This is all the code I have which uses an external JSON parser at
> > present.
> > > It serializes and deserializes JSON-RPC (based on latest draft spec) very
> > > pedantically to/from Eina_Value, and all strings get stringshared.
> > >
> > >
> > http://git.enlightenment.org/devs/discomfitor/maelstrom.git/tree/src/lib/azy/azy_content_json.c
> >
> > ok. so still about 500 loc to drive cjson and convert back to data structs
> > (eina-value in this case). and... behind "getobjectitem" in cjson is
> > probably
> > a hash... and probably a set of lists... etc. duplicating strings inside of
> > cjson that then are extracted and stuffed into stringshare strings. :)
>
>
> > and we ned up with another fun thing... to use cjson... at least ubuntu
> > users
> > can't just apt-get install it. no package. so we have to copy it into the
> > efl
> > tree or make packages or force pl to download and compile it just for a
> > small
> > lib dep... and it nicely comes with a zip file with no makefile or
> > configure...
> > or any build infra, with __MACOSX metadata hidden files all thru the zip...
> > good luck with that.
>
> Oh noes, scary __UNDERSCORE files and lack of build system which are
> irrelevant when importing the source!
it's more a matter of saying "we dont have to maintain a json parser then if we
just use an external one"... if u import it.. then u are going to be
maintaining it. if you don't then the above pretty much means its not available
as a package to link to AND has a low chance of acceptance asking people to go
download the zip file and figure out how to compile a .so themselves by hand. i
covered the case of importing as the other option below.
> > so import the src entirely is the only way... and then... take a read of
> > the
> > src. seriously. once we import it we will have to fix it and maintain it
> > entirely... THIS is just one of many functions where the WHOLE function
> > including definition is on a single line:
> >
> > void cJSON_ReplaceItemInObject(cJSON *object,const char *string,cJSON
> > *newitem){int i=0;cJSON *c=object->child;while(c && cJSON_strcasecmp
> > (c->string,string))i++,c=c->next;if(c){newitem->string=cJSON_strdup
> > (string);cJSON_ReplaceItemInArray(object,i,newitem);}}
> >
> > no newlines. there's a whole batch of these 11-liner funcs there, it's not
> > a
> > one-off oh an i was wrong. it has no lists or hashes. it just has arrays of
> > string->value and cJSON_GetObjectItem is... a linear O(n) walk thru the
> > array
> > strcmping every item until key found, then return... so for objects with
> > lots
> > of keys... we're talking a lot of walking... might be doable for like
> > things
> > with < 10 keys... not so for a more expansive and generic need.
> >
> > so a quick 5 minute evaluation of cjson tells me:
> >
> > 1. we can't just link to it... and HAVE to import it.
>
> That's the entire idea behind having a sub-1000 line parser, which is one
> of the cornerstones of Cedric's stance that we should write our won.
it then means we end up forking it and having to maintain it.
> > 2. it's coding conventions are far from what we are used to and do in efl
> > land,
> > so we'll have a nice "sore thumb" inside our src tree.
>
> Cedric's coding conventions are pretty far from it too, but we still let
> him work on Edje.
read cjson. not only is it pretty far... its in a whole other galaxy...
seriously. entire functions in 1 line of code with almost zero whitespace
we'll end up reformatting these just to read it... and once we reformat.. we
fork. and when we fork.. we now maintain fully. like all forks it becomes
totally our cost/responsibility.
> > 3. it will duplicate all things via "strdups" so we can't hope to minimize
> > string copies in memory.
> >
>
> Not a great argument since we could easily just s/strdup/stringshare/.
as above. becomes a fork. when we then make it use eina hash too and more
internally we basically now maintain a json parser anyway.. it ju
Re: [E-devel] JSON parser in Eina - together we can stop the madness
No, we added SOAP. On Thu, May 2, 2013 at 6:22 AM, David Seikel wrote: > Er, somehow this thread went from "stop the JSON madness" to "this is > how we should do JSON"? I need caffeine, I'm not keeping up. Though I > blame E, it's dog slow now. Did someone add JSON? :-P > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. > > > -- > 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
Re: [E-devel] JSON parser in Eina - together we can stop the madness
Er, somehow this thread went from "stop the JSON madness" to "this is how we should do JSON"? I need caffeine, I'm not keeping up. Though I blame E, it's dog slow now. Did someone add JSON? :-P -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- 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
Re: [E-devel] JSON parser in Eina - together we can stop the madness
On Thu, May 2, 2013 at 1:04 AM, Carsten Haitzler wrote:
> On Wed, 1 May 2013 14:56:32 +0100 Michael Blumenkrantz
> said:
>
> > cJSON, at least, exposes no hashes, lists, or any of that; I don't know
> > what crazy parsers you kids have been using which do this, but they
> > shouldn't since JSON doesn't have any concept of such things.
>
> errr.. json is really a tree of string key -> values (where value can be a
> subtree) so thus by nature its a list and/or hash of strings and/or
> subtrees
> make sense.
>
If you're using JSON for RPC, it doesn't make sense. This is a very common
use case.
>
> > This is all the code I have which uses an external JSON parser at
> present.
> > It serializes and deserializes JSON-RPC (based on latest draft spec) very
> > pedantically to/from Eina_Value, and all strings get stringshared.
> >
> >
> http://git.enlightenment.org/devs/discomfitor/maelstrom.git/tree/src/lib/azy/azy_content_json.c
>
> ok. so still about 500 loc to drive cjson and convert back to data structs
> (eina-value in this case). and... behind "getobjectitem" in cjson is
> probably
> a hash... and probably a set of lists... etc. duplicating strings inside of
> cjson that then are extracted and stuffed into stringshare strings. :)
> and we ned up with another fun thing... to use cjson... at least ubuntu
> users
> can't just apt-get install it. no package. so we have to copy it into the
> efl
> tree or make packages or force pl to download and compile it just for a
> small
> lib dep... and it nicely comes with a zip file with no makefile or
> configure...
> or any build infra, with __MACOSX metadata hidden files all thru the zip...
> good luck with that.
>
Oh noes, scary __UNDERSCORE files and lack of build system which are
irrelevant when importing the source!
>
> so import the src entirely is the only way... and then... take a read of
> the
> src. seriously. once we import it we will have to fix it and maintain it
> entirely... THIS is just one of many functions where the WHOLE function
> including definition is on a single line:
>
> void cJSON_ReplaceItemInObject(cJSON *object,const char *string,cJSON
> *newitem){int i=0;cJSON *c=object->child;while(c && cJSON_strcasecmp
> (c->string,string))i++,c=c->next;if(c){newitem->string=cJSON_strdup
> (string);cJSON_ReplaceItemInArray(object,i,newitem);}}
>
> no newlines. there's a whole batch of these 11-liner funcs there, it's not
> a
> one-off oh an i was wrong. it has no lists or hashes. it just has arrays of
> string->value and cJSON_GetObjectItem is... a linear O(n) walk thru the
> array
> strcmping every item until key found, then return... so for objects with
> lots
> of keys... we're talking a lot of walking... might be doable for like
> things
> with < 10 keys... not so for a more expansive and generic need.
>
> so a quick 5 minute evaluation of cjson tells me:
>
> 1. we can't just link to it... and HAVE to import it.
>
That's the entire idea behind having a sub-1000 line parser, which is one
of the cornerstones of Cedric's stance that we should write our won.
> 2. it's coding conventions are far from what we are used to and do in efl
> land,
> so we'll have a nice "sore thumb" inside our src tree.
>
Cedric's coding conventions are pretty far from it too, but we still let
him work on Edje.
> 3. it will duplicate all things via "strdups" so we can't hope to minimize
> string copies in memory.
>
Not a great argument since we could easily just s/strdup/stringshare/.
> 4. walking cjson stuff is either looking up every key you want with O(n)
> per
> lookup with strcmps ... OR... walking the array by index and converting to
> a
> hash then doing hash lookups (back to #3).
>
This is a valid point, and really the only one you've made. cJSON is NOT
great for a general use case. It fits the needs of RPC perfectly, but
that's about it.
> 5. conclusion... cjson would not be the best choice of json parser to roll
> into
> our src tree... :)
>
> > On Wed, May 1, 2013 at 2:46 PM, Tom Hacohen
> wrote:
> >
> > > On 01/05/13 14:15, Cedric BAIL wrote:
> > > > WTF ! I am not saying that without a benchmark ! Where do you think
> > > > that came from ? Just random praising for the fun ?
> > >
> > > You said you haven't tested cJSON, only json-c. I asked you about it!>
> > > > Because there is no complexity there. It just work. There is no
> > > > maintenance cost. There is no need to bring an external dependency
> for
> > > > 100 lines of code.
> > >
> > > Pfft yeah, sounds like every other piece of code every written.
> > >
> > > >
> > > >> Mike can interject, as he has used cJSON before, and I don't
> remember
> > > him
> > > >> mentioning any issues.
> > > >
> > > > So running cJSON, then converting to Eina_Value or C structure by
> hand
> > > > in the application side is faster than just running a stupid automate
> > > > that produce them in the first place...
> > >
> > > Let's wait for mike. I wonder what he did. Also I wonder if you'd end
> up
>
Re: [E-devel] JSON parser in Eina - together we can stop the madness
On Wed, 1 May 2013 14:56:32 +0100 Michael Blumenkrantz
said:
> cJSON, at least, exposes no hashes, lists, or any of that; I don't know
> what crazy parsers you kids have been using which do this, but they
> shouldn't since JSON doesn't have any concept of such things.
errr.. json is really a tree of string key -> values (where value can be a
subtree) so thus by nature its a list and/or hash of strings and/or subtrees
make sense.
> This is all the code I have which uses an external JSON parser at present.
> It serializes and deserializes JSON-RPC (based on latest draft spec) very
> pedantically to/from Eina_Value, and all strings get stringshared.
>
> http://git.enlightenment.org/devs/discomfitor/maelstrom.git/tree/src/lib/azy/azy_content_json.c
ok. so still about 500 loc to drive cjson and convert back to data structs
(eina-value in this case). and... behind "getobjectitem" in cjson is probably
a hash... and probably a set of lists... etc. duplicating strings inside of
cjson that then are extracted and stuffed into stringshare strings. :)
and we ned up with another fun thing... to use cjson... at least ubuntu users
can't just apt-get install it. no package. so we have to copy it into the efl
tree or make packages or force pl to download and compile it just for a small
lib dep... and it nicely comes with a zip file with no makefile or configure...
or any build infra, with __MACOSX metadata hidden files all thru the zip...
good luck with that.
so import the src entirely is the only way... and then... take a read of the
src. seriously. once we import it we will have to fix it and maintain it
entirely... THIS is just one of many functions where the WHOLE function
including definition is on a single line:
void cJSON_ReplaceItemInObject(cJSON *object,const char *string,cJSON
*newitem){int i=0;cJSON *c=object->child;while(c && cJSON_strcasecmp
(c->string,string))i++,c=c->next;if(c){newitem->string=cJSON_strdup
(string);cJSON_ReplaceItemInArray(object,i,newitem);}}
no newlines. there's a whole batch of these 11-liner funcs there, it's not a
one-off oh an i was wrong. it has no lists or hashes. it just has arrays of
string->value and cJSON_GetObjectItem is... a linear O(n) walk thru the array
strcmping every item until key found, then return... so for objects with lots
of keys... we're talking a lot of walking... might be doable for like things
with < 10 keys... not so for a more expansive and generic need.
so a quick 5 minute evaluation of cjson tells me:
1. we can't just link to it... and HAVE to import it.
2. it's coding conventions are far from what we are used to and do in efl land,
so we'll have a nice "sore thumb" inside our src tree.
3. it will duplicate all things via "strdups" so we can't hope to minimize
string copies in memory.
4. walking cjson stuff is either looking up every key you want with O(n) per
lookup with strcmps ... OR... walking the array by index and converting to a
hash then doing hash lookups (back to #3).
5. conclusion... cjson would not be the best choice of json parser to roll into
our src tree... :)
> On Wed, May 1, 2013 at 2:46 PM, Tom Hacohen wrote:
>
> > On 01/05/13 14:15, Cedric BAIL wrote:
> > > WTF ! I am not saying that without a benchmark ! Where do you think
> > > that came from ? Just random praising for the fun ?
> >
> > You said you haven't tested cJSON, only json-c. I asked you about it!>
> > > Because there is no complexity there. It just work. There is no
> > > maintenance cost. There is no need to bring an external dependency for
> > > 100 lines of code.
> >
> > Pfft yeah, sounds like every other piece of code every written.
> >
> > >
> > >> Mike can interject, as he has used cJSON before, and I don't remember
> > him
> > >> mentioning any issues.
> > >
> > > So running cJSON, then converting to Eina_Value or C structure by hand
> > > in the application side is faster than just running a stupid automate
> > > that produce them in the first place...
> >
> > Let's wait for mike. I wonder what he did. Also I wonder if you'd end up
> > changing the Eina_Value and lists to your own struct anyway 99.99% of
> > the time. Surely there must be a lib that let's you parse it straight to
> > your data type, but that might be slower.
> >
> > >
> > >> 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?
> > >
> > > Because it is damn easy to write one implementation ! Because most of
> > > the speed doesn't come from the parser automate who is always the same
> > > stupid table, but from the hash, object, list and array object
> > > manipulated. That is where the cost come from. And I am not only
> > > arguing about speed, but also integration and simplicity of use.
> > > Really forcing everyone to link with another librar
Re: [E-devel] JSON parser in Eina - together we can stop the madness
cJSON, at least, exposes no hashes, lists, or any of that; I don't know what crazy parsers you kids have been using which do this, but they shouldn't since JSON doesn't have any concept of such things. This is all the code I have which uses an external JSON parser at present. It serializes and deserializes JSON-RPC (based on latest draft spec) very pedantically to/from Eina_Value, and all strings get stringshared. http://git.enlightenment.org/devs/discomfitor/maelstrom.git/tree/src/lib/azy/azy_content_json.c On Wed, May 1, 2013 at 2:46 PM, Tom Hacohen wrote: > On 01/05/13 14:15, Cedric BAIL wrote: > > WTF ! I am not saying that without a benchmark ! Where do you think > > that came from ? Just random praising for the fun ? > > You said you haven't tested cJSON, only json-c. I asked you about it!> > > Because there is no complexity there. It just work. There is no > > maintenance cost. There is no need to bring an external dependency for > > 100 lines of code. > > Pfft yeah, sounds like every other piece of code every written. > > > > >> Mike can interject, as he has used cJSON before, and I don't remember > him > >> mentioning any issues. > > > > So running cJSON, then converting to Eina_Value or C structure by hand > > in the application side is faster than just running a stupid automate > > that produce them in the first place... > > Let's wait for mike. I wonder what he did. Also I wonder if you'd end up > changing the Eina_Value and lists to your own struct anyway 99.99% of > the time. Surely there must be a lib that let's you parse it straight to > your data type, but that might be slower. > > > > >> 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? > > > > Because it is damn easy to write one implementation ! Because most of > > the speed doesn't come from the parser automate who is always the same > > stupid table, but from the hash, object, list and array object > > manipulated. That is where the cost come from. And I am not only > > arguing about speed, but also integration and simplicity of use. > > Really forcing everyone to link with another library for less than > > 1000 lines of code, to have another object api to manipulate, to do > > all the conversion manually is a great help to every one. Of course it > > is doable in the application. Of course you can write your own, it is > > so damn easy. > > > > As for the benchmark, we are going to reuse the one written by QT. I > > am going to do proper review and cleaning as necessary after 1.9, > > there is nothing to look at at this stage. I have already spend more > > time arguing on that subject that I am sure it will take me to write > > an implementation from scratch and likely to ever maintain it. > > Let's wait for the benchmarks then. I find it really odd that the only > different in speed is the implementations of the hash-tables and lists. > > -- > 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
Re: [E-devel] JSON parser in Eina - together we can stop the madness
On Wed, 1 May 2013 14:26:12 +0100 Michael Blumenkrantz 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 > > 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. > > > > > > > > > > > -- > > >
Re: [E-devel] JSON parser in Eina - together we can stop the madness
On 01/05/13 14:15, Cedric BAIL wrote: > WTF ! I am not saying that without a benchmark ! Where do you think > that came from ? Just random praising for the fun ? You said you haven't tested cJSON, only json-c. I asked you about it!> > Because there is no complexity there. It just work. There is no > maintenance cost. There is no need to bring an external dependency for > 100 lines of code. Pfft yeah, sounds like every other piece of code every written. > >> Mike can interject, as he has used cJSON before, and I don't remember him >> mentioning any issues. > > So running cJSON, then converting to Eina_Value or C structure by hand > in the application side is faster than just running a stupid automate > that produce them in the first place... Let's wait for mike. I wonder what he did. Also I wonder if you'd end up changing the Eina_Value and lists to your own struct anyway 99.99% of the time. Surely there must be a lib that let's you parse it straight to your data type, but that might be slower. > >> 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? > > Because it is damn easy to write one implementation ! Because most of > the speed doesn't come from the parser automate who is always the same > stupid table, but from the hash, object, list and array object > manipulated. That is where the cost come from. And I am not only > arguing about speed, but also integration and simplicity of use. > Really forcing everyone to link with another library for less than > 1000 lines of code, to have another object api to manipulate, to do > all the conversion manually is a great help to every one. Of course it > is doable in the application. Of course you can write your own, it is > so damn easy. > > As for the benchmark, we are going to reuse the one written by QT. I > am going to do proper review and cleaning as necessary after 1.9, > there is nothing to look at at this stage. I have already spend more > time arguing on that subject that I am sure it will take me to write > an implementation from scratch and likely to ever maintain it. Let's wait for the benchmarks then. I find it really odd that the only different in speed is the implementations of the hash-tables and lists. -- 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
Re: [E-devel] JSON parser in Eina - together we can stop the madness
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 > 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 > > > > > >
Re: [E-devel] JSON parser in Eina - together we can stop the madness
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 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/listinf
Re: [E-devel] JSON parser in Eina - together we can stop the madness
On 01/05/13 13:13, Cedric BAIL wrote: > On Wed, May 1, 2013 at 6:38 PM, Tom Hacohen 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. -- 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
Re: [E-devel] JSON parser in Eina - together we can stop the madness
On Wed, 1 May 2013 21:13:37 +0900 Cedric BAIL said: > On Wed, May 1, 2013 at 6:38 PM, Tom Hacohen 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... i will say.. it depends on the parser. if its sax-like then it doesnt expose/fill in any data structs etc. but if it is exposing hashes, lists etc. then the usefulness of a non-efl parser becomes exceedingly low as we now invest 1k lines of code in converting/transporting data back and forth anyway. -- - 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
Re: [E-devel] JSON parser in Eina - together we can stop the madness
On Wed, May 1, 2013 at 6:38 PM, Tom Hacohen 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
Re: [E-devel] JSON parser in Eina - together we can stop the madness
On 01/05/13 11:12, David Seikel wrote: > On Wed, 1 May 2013 10:43:39 +0100 Michael Blumenkrantz > 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 >> 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-) He wants to use JSON as a text way of representing data. I.e he's aiming to replace the eet language, not the eet binary protocol. So it's not exactly that. Even if it was an outside of the efl but in e land project, it would have been a PITA, as we'd still have to maintain it. The point here is not whether or not Daniel should use JSON, but more: should we accept this unneeded wheel re-invention. -- 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
Re: [E-devel] JSON parser in Eina - together we can stop the madness
On Wed, 1 May 2013 20:12:25 +1000 David Seikel wrote: > On Wed, 1 May 2013 10:43:39 +0100 Michael Blumenkrantz > 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 > > 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
Re: [E-devel] JSON parser in Eina - together we can stop the madness
On Wed, 1 May 2013 10:43:39 +0100 Michael Blumenkrantz 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 > 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
Re: [E-devel] JSON parser in Eina - together we can stop the madness
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. On Wed, May 1, 2013 at 10:38 AM, Tom Hacohen 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. > > -- > 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
[E-devel] JSON parser in Eina - together we can stop the madness
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. -- 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
