In the examples of the json spec (http://tools.ietf.org/html/rfc4627), he
never leaves an extra comma after the strings or objects, but in our
canonicaldb.json we are doing it:
"john.doe" : [{
"id" : "1",
"userId" : "john.doe",
"title" : "yellow",
"body" : "what a color!", --->HERE!
}],
"schools" : [{
"address" : {
"unstructuredAddress" : "1 Edu St.", ----->HERE!
},
"description" : "High School",
"endDate" : "1991-01-01",
"field" : "",
"name" : "",
"salary" : "",
"startDate" : "1982-01-01",
"subField" : "",
"title" : "",
"webpage" : ""
}],
This is what i meant before... can we only fix this and i'll remove the
comments with regexp ?
G.-
On Wed, Jul 23, 2008 at 4:03 PM, Chris Chabot <[EMAIL PROTECTED]> wrote:
> On Jul 23, 2008, at 8:28 PM, Louis Ryan wrote:
>
> We could though technically the extra ',' is allowed by the JSON spec and
>> there's a reasonable chance you'll get JSON with these artifacts coming in
>> from 3rd parties on the RESTful API. What are the library options on the
>> PHP side to have a more tolerant parser.
>>
>
> We certainly did experiment with this, but the only viable (production
> ready) solution is a metric ton of native php code, which is 10000x slower,
> slows down the QPM severely (due to the way apache/php loads in the code on
> every request) and crashing on other particularities again, in other words
> not so terribly much :)
>
>
> For comments we can certainly adopt a convetion to use comments on
>> newlines
>> only within Shindig if that helps.
>>
>
> Nah comments are no problem, all we need to do is strip them from the
> content before parsing it, not optimal but certainly not so bad that i would
> want to try to enforce such rules.
>
> -- Chris
>
