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

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

Expand Messages
  • Jakob Kruse
    Andrea, I fail to understand what exactly you aim to prove on that page, but that is besides the point. You seem to argue that special features (incorporating
    Message 1 of 3 , Aug 11, 2009
    • 0 Attachment
      Andrea,

      I fail to understand what exactly you aim to prove on that page, but that is besides the point. You seem to argue that special features (incorporating the use of one of Crockfords declared ultimate evils: eval) should be included into a JSON parsing library created by same Crockford, in order to better support the parsing of dates – a non-feature of JSON.

      I think it is safe to say you are fighting a lost cause.

      If you really want to speed things up, don’t let the JSON parser do date deserializing. Keep your dates as strings as long as possible, and only deserialize them (using whichever method you fancy) when you need them. I’m quite sure that will improve speed even more than your suggestion.

      Kind regards,
      Jakob

      Fra: json@yahoogroups.com [mailto:json@yahoogroups.com] På vegne af Andrea Giammarchi
      Sendt: 11. august 2009 17:57
      Til: json@yahoogroups.com
      Emne: Re: [json] Re: Why we have to waist our time for Date parsing?


      I wrote a page days ago which aim is to demonstrate there was nothing
      hypothetical:
      http://www.3site.eu/jstests/json/

      Would be nice to receive an answer or a test that demonstrate I was wrong.

      Regards

      [Non-text portions of this message have been removed]
    • Andrea Giammarchi
      ... Douglas blamed me for hypothetical assumptions about performances improvements, I ve simply demonstrated those were not assumptions. My point is: how
      Message 2 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 3 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.