maybe a complex RegEx can detect and remove the trailing ','

still, is easier and more efficient to just "dont put it"
ropu

On Thu, Jul 24, 2008 at 10:58 AM, Gonzalo Aune <[EMAIL PROTECTED]>
wrote:

> 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
> >
>



-- 
.-. --- .--. ..-
R o p u

Reply via email to