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
    ... Douglas blamed me for hypothetical assumptions about performances improvements, I ve simply demonstrated those were not assumptions. My point is: how
    Message 1 of 3 , Aug 11, 2009
    • 0 Attachment
      On Tue, Aug 11, 2009 at 9:19 PM, Jakob Kruse <kruse@...> wrote:

      > I fail to understand what exactly you aim to prove on that page
      >



      Douglas blamed me for hypothetical assumptions about performances
      improvements, I've simply demonstrated those were not assumptions.

      My point is: how flexible should be a standard or its implementation?

      I did not write to ask the world to change JSON, ASCII or whatever solid
      standard, I just put on the table a couple of facts:
      1 - one of the most common usage of the second argument, is to normalize
      back dates, 'cause since dates are serialized as special objects, I do not
      get why we should loose their meaning once evaluated
      2 - with a simple replace after whatever check, without affecting anything,
      performances are 2 to 5 times better to obtain the same result. If this was
      in core obviously performances would be even better.

      I agree that a parser should implement a check for each encountered string
      during de-serialization, and this means simply less performances, generally
      speaking, but as the official JSON parser is now dictating methods and
      arguments, how difficult would be to implement eventually a method a part
      able to automatically parse back dates?

      JSON.parseISO = function(jstring, reviewer){
      // exactly the same stuff plus the suggested regexp before the
      "evaluation"
      };

      A simple thing like this, without affecting the protocol itself, will remove
      the only problem I could spot with the JSON format.
      Every JSON porting has Regular Expressions but I could write a C "char to
      char" parser to understand ISO strings and tell you how fast/slow it will be
      without regexp (hopefully faster)

      Here latest consideration about this eval evil topic that should never be
      misunderstood, imho:

      1 - even native JSON implementations allow a script to redefine the parse
      method, so JSON.parse is not safer than anything else
      2 - if we are worried about a possible modified Date constructor, we should
      be worried about eval itself which could be redefined and then modified (so
      if the Date is modified from some malicious code, I bet eval has been
      modified before)
      3 - JSON is mainly used via Ajax as protocol, Ajax has its own security
      policy and if we use a proxy in our server obviously we can maniacally parse
      responses but we are doing something wrong unless we do not trust 100% that
      source
      4 - if we think about JSONP we should "pray" every day nothing is gonna
      happen in "that server" but hopefully, a JSONP is free from the format and
      it could avoid stress passing directly instances ( oh no wait, it won't be
      JSONP anymore then ... old style CSS or Cross Domain Scripts again? )

      All this concern about eval/evil when it is simply the fastest way to
      "transform" a JSON string, together with head.appendChild(script), sandbox
      evaluation which is still not safe, or whatever manually implemented method,
      considering it could be modified, cannot be a constant justification able to
      eventually block future improvements to the protocol or just to its official
      methods.
      Obviously an improvement makes sense only if there are benefits for every
      developer and every device.
      This is my only point if the problem is: I do not want a new Date in my JSON
      string before its parsed.
      I hope it is clear, if not, it will be my pleasure to better explain my
      point of view.

      Best Regards


      [Non-text portions of this message have been removed]
    • Fang Yidong
      Hi Andrea, I don t think there is an official JSON parser, neither it will dictate anything. I think you can consider it as a reference implementation if
      Message 2 of 3 , Aug 11, 2009
      • 0 Attachment
        Hi Andrea,

        I don't think there is an "official" JSON parser, neither it will "dictate" anything. I think you can consider it as a reference implementation if it's written by Douglas.

        In my opinion, Douglas (and JSON.org) focus on the JSON specification itself,  while developers can contribute to its implementation/library. So if you think you can improve the performance of some libraries, you can make an extension/enhancement, something like that. But we are not talking about the JSON specification. I think the specification and the implementation are quite different, and it's not always a simple thing to add some "features" to a specication, because we have so many things to be taken into consideration.

        Thanks.

        --

        JSON: Action in AJAX!



        JSON - http://www.json.org

        JSON.simple - http://code.google.com/p/json-simple/


        发件人: Andrea Giammarchi <andrea.giammarchi@...>
        主题: Re: [json] Re: Why we have to waist our time for Date parsing?
        收件人: json@yahoogroups.com
        日期: 2009年8月12日,周三,上午5:15






         





        On Tue, Aug 11, 2009 at 9:19 PM, Jakob Kruse <kruse@kruse- net.dk> wrote:



        > I fail to understand what exactly you aim to prove on that page

        >



        Douglas blamed me for hypothetical assumptions about performances

        improvements, I've simply demonstrated those were not assumptions.



        My point is: how flexible should be a standard or its implementation?



        I did not write to ask the world to change JSON, ASCII or whatever solid

        standard, I just put on the table a couple of facts:

        1 - one of the most common usage of the second argument, is to normalize

        back dates, 'cause since dates are serialized as special objects, I do not

        get why we should loose their meaning once evaluated

        2 - with a simple replace after whatever check, without affecting anything,

        performances are 2 to 5 times better to obtain the same result. If this was

        in core obviously performances would be even better.



        I agree that a parser should implement a check for each encountered string

        during de-serialization, and this means simply less performances, generally

        speaking, but as the official JSON parser is now dictating methods and

        arguments, how difficult would be to implement eventually a method a part

        able to automatically parse back dates?



        JSON.parseISO = function(jstring, reviewer){

        // exactly the same stuff plus the suggested regexp before the

        "evaluation"

        };



        A simple thing like this, without affecting the protocol itself, will remove

        the only problem I could spot with the JSON format.

        Every JSON porting has Regular Expressions but I could write a C "char to

        char" parser to understand ISO strings and tell you how fast/slow it will be

        without regexp (hopefully faster)



        Here latest consideration about this eval evil topic that should never be

        misunderstood, imho:



        1 - even native JSON implementations allow a script to redefine the parse

        method, so JSON.parse is not safer than anything else

        2 - if we are worried about a possible modified Date constructor, we should

        be worried about eval itself which could be redefined and then modified (so

        if the Date is modified from some malicious code, I bet eval has been

        modified before)

        3 - JSON is mainly used via Ajax as protocol, Ajax has its own security

        policy and if we use a proxy in our server obviously we can maniacally parse

        responses but we are doing something wrong unless we do not trust 100% that

        source

        4 - if we think about JSONP we should "pray" every day nothing is gonna

        happen in "that server" but hopefully, a JSONP is free from the format and

        it could avoid stress passing directly instances ( oh no wait, it won't be

        JSONP anymore then ... old style CSS or Cross Domain Scripts again? )



        All this concern about eval/evil when it is simply the fastest way to

        "transform" a JSON string, together with head.appendChild( script), sandbox

        evaluation which is still not safe, or whatever manually implemented method,

        considering it could be modified, cannot be a constant justification able to

        eventually block future improvements to the protocol or just to its official

        methods.

        Obviously an improvement makes sense only if there are benefits for every

        developer and every device.

        This is my only point if the problem is: I do not want a new Date in my JSON

        string before its parsed.

        I hope it is clear, if not, it will be my pleasure to better explain my

        point of view.



        Best Regards



        [Non-text portions of this message have been removed]





























        ___________________________________________________________
        好玩贺卡等你发,邮箱贺卡全新上线!
        http://card.mail.cn.yahoo.com/

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