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

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

Expand Messages
  • 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 1 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.