Loading ...
Sorry, an error occurred while loading the content.

Re: [json] Re: Why we have to waist our time for Date parsing?

Expand Messages
  • Andrea Giammarchi
    OK guys, I ve got your point. About dictating it was what Douglas said: ES5 and every browser are going to implement json2.js serializer/unserializer API.
    Message 1 of 33 , Aug 12, 2009
    • 0 Attachment
      OK guys, I've got your point.

      About "dictating" it was what Douglas said: ES5 and every browser are going
      to implement json2.js serializer/unserializer API.
      JSON is basically JavaScript "quirk" syntax, eval without modifications
      indeed, it comes from ECMAScript specs, and it uses string transformed from
      Unicode, again JavaScript natural strings encoding.

      I thought this mailing list was not only about the protocol, but about
      everything around it, parsers included, I was obviously wrong.

      If you manage JSON via server side languages and/or for databases does not
      change that much the fact dates are a lost transformations.

      Again, I never thought about changing JSON protocol as is, I just considered
      there is a Date unofficial convention, every parser manages it, which does
      not come back Dates and I suggested a parser modification/implementation
      that cannot break or change the JSON protocol itself at all.

      It is easy for me to change the json2.js file as is to add a method in
      browsers JSON object but obviously if it was something discussed and
      implemented, I am talking about parseISO or whatever name you prefer, it
      would have been good for everybody, without breaking what we have so far,
      and simply adding a common transformation back parser method for every
      language.

      Best Regards


      [Non-text portions of this message have been removed]
    • Martin Cooper
      On Wed, Aug 12, 2009 at 10:15 AM, Andrea Giammarchi
      Message 33 of 33 , Aug 12, 2009
      • 0 Attachment
        On Wed, Aug 12, 2009 at 10:15 AM, Andrea Giammarchi <
        andrea.giammarchi@...> wrote:

        > I have created dunno how many JSON open source parsers but json2.js is
        > apparently frequently updated and being the "unofficial" standard adopted
        > by
        > most recent browsers tell me why "we", as developers, should put effort for
        > something that is already defined elsewhere where posts like "please
        > consider this feature" are not considered at all (neither welcome)


        I think you just answered your own question. The reason you, or I, or
        someone else, would create a project on, say, Google Code, for a new JSON
        implementation is precisely so that posts like "please consider this
        feature" *are* considered.

        As for creating a project separate, and different, from the "unofficial"
        standard, there are numerous cases of open source alternatives to reference
        implementations, including cases in which the alternatives have become at
        least as widely used as the RIs themselves.

        --
        Martin Cooper



        > On Wed, Aug 12, 2009 at 5:26 PM, Martin Cooper <mfncooper@...>
        > wrote:
        >
        > >
        > >
        > > Fang is correct that there is no "official" JSON parser, and also that
        > > json2.js could be considered a reference implementation (RI).
        > >
        > > Since Douglas unilaterally controls this RI, it is only ever going to
        > > include what is in the JSON specification, or what Douglas perceives will
        > > become part of a future version of that specification.
        > >
        > > More than once, I've considered taking the code from json2.js (which is
        > > Public Domain, after all), creating an open source project out of it, and
        > > enhancing it to do things a bit differently and / or add capabilities
        > that
        > > I've seen a need for and people have expressed a desire for. It's my
        > > impression that so many people use json2.js simply because it's there and
        > > because nobody has gone ahead and forked it into a more complete library.
        > > Why have I not done that? Honestly, just laziness up to now. It's not
        > like
        > > I
        > > haven't done open source before. ;-)
        > >
        > > --
        > > Martin Cooper
        > >
        > >
        > > On Wed, Aug 12, 2009 at 12:06 AM, Andrea Giammarchi <
        > > andrea.giammarchi@... <andrea.giammarchi%40gmail.com>> wrote:
        > >
        > > > OK guys, I've got your point.
        > > >
        > > > About "dictating" it was what Douglas said: ES5 and every browser are
        > > going
        > > > to implement json2.js serializer/unserializer API.
        > > > JSON is basically JavaScript "quirk" syntax, eval without modifications
        > > > indeed, it comes from ECMAScript specs, and it uses string transformed
        > > from
        > > > Unicode, again JavaScript natural strings encoding.
        > > >
        > > > I thought this mailing list was not only about the protocol, but about
        > > > everything around it, parsers included, I was obviously wrong.
        > > >
        > > > If you manage JSON via server side languages and/or for databases does
        > > not
        > > > change that much the fact dates are a lost transformations.
        > > >
        > > > Again, I never thought about changing JSON protocol as is, I just
        > > > considered
        > > > there is a Date unofficial convention, every parser manages it, which
        > > does
        > > > not come back Dates and I suggested a parser
        > modification/implementation
        > > > that cannot break or change the JSON protocol itself at all.
        > > >
        > > > It is easy for me to change the json2.js file as is to add a method in
        > > > browsers JSON object but obviously if it was something discussed and
        > > > implemented, I am talking about parseISO or whatever name you prefer,
        > it
        > > > would have been good for everybody, without breaking what we have so
        > far,
        > > > and simply adding a common transformation back parser method for every
        > > > language.
        > > >
        > > > Best Regards
        > > >
        > > >
        > > > [Non-text portions of this message have been removed]
        > > >
        > > >
        > > >
        > > > ------------------------------------
        > > >
        > > > Yahoo! Groups Links
        > > >
        > > >
        > > >
        > > >
        > >
        > > [Non-text portions of this message have been removed]
        > >
        > >
        > >
        >
        >
        > [Non-text portions of this message have been removed]
        >
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >
        >


        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.