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

Re: JSONRequest

Expand Messages
  • Douglas Crockford
    ... You re right.
    Message 1 of 22 , Oct 11, 2007
    View Source
    • 0 Attachment
      --- In json@yahoogroups.com, John David Duncan <john.david.duncan@...>
      wrote:

      > The Firefox plugin chooses to send an "Accept: application/
      > jsonrequest" header with the request, and I agree with this idea.
      > The proposal says that if the request is application/jsonrequest,
      > then the response must also be application/jsonrequest; the Accept
      > header spells out this requirement plainly in HTTP. In my opinion,
      > the header should be mandatory.

      You're right.
    • Michael Schwarz
      Hi, one thing I didn t get a answer yet about security: I expect that NTLM is not working with JSONRequest, too, is that correct? Some other questions while
      Message 2 of 22 , Oct 14, 2007
      View Source
      • 0 Attachment
        Hi,

        one thing I didn't get a answer yet about security: I expect that NTLM is
        not working with JSONRequest, too, is that correct?

        Some other questions while implementing a client plugin: must there be a
        maximum timeout value? I think that it makes no sence to run requests longer
        than 10 seconds. What about the user-agent string, will this be sent or not?
        Why only send the domain, doesn't the complete Uri makes sence?

        And one last question: does the JSON server need to support HTTP 1.0, or is
        it mandatory to support HTTP 1.1 only?

        Michael



        On 10/11/07, Douglas Crockford <douglas@...> wrote:
        >
        > --- In json@yahoogroups.com <json%40yahoogroups.com>, John David Duncan
        > <john.david.duncan@...>
        > wrote:
        >
        > > The Firefox plugin chooses to send an "Accept: application/
        > > jsonrequest" header with the request, and I agree with this idea.
        > > The proposal says that if the request is application/jsonrequest,
        > > then the response must also be application/jsonrequest; the Accept
        > > header spells out this requirement plainly in HTTP. In my opinion,
        > > the header should be mandatory.
        >
        > You're right.
        >
        >
        >



        --
        Best regards | Schöne Grüße
        Michael

        Microsoft MVP - Most Valuable Professional
        Microsoft MCAD - Certified Application Developer

        http://weblogs.asp.net/mschwarz/
        http://www.ajaxpro.info/

        Skype: callto:schwarz-interactive
        MSN IM: passport@...


        [Non-text portions of this message have been removed]
      • collin_jackson
        ... Can you tell us which platform you are developing a client plugin for? ... The browser s security policy isn t granular enough to separate URIs into
        Message 3 of 22 , Oct 14, 2007
        View Source
        • 0 Attachment
          --- In json@yahoogroups.com, "Michael Schwarz" <michael.schwarz@...>
          wrote:
          > Some other questions while implementing a client plugin:

          Can you tell us which platform you are developing a client plugin for?

          > Why only send the domain, doesn't the complete Uri makes sence?

          The browser's security policy isn't granular enough to separate URIs
          into separate security contexts, so it would be easy for a site to
          spoof any URI within the page's a given domain by injecting script
          tags into other pages. Also, in Firefox (for example) there are many
          scenarios where a page has URI that does not specify a domain
          (about:blank, or a javascript: URI) yet the page does have a domain
          according to the browser.

          To make this header match the browser's security policy, it would be
          possible to set a header of the form scheme://domain:port (with no
          path included), but I'm not sure whether this is necessary.
        • Michael Schwarz
          Hi, ... I write one for Mac and Windows, well, it is not a real plugin, but a way to integrate it in you web pages. ... What I thought was pages like
          Message 4 of 22 , Oct 14, 2007
          View Source
          • 0 Attachment
            Hi,

            On 10/14/07, collin_jackson <yahoo@...> wrote:
            > --- In json@yahoogroups.com, "Michael Schwarz" <michael.schwarz@...>
            > wrote:
            > > Some other questions while implementing a client plugin:
            >
            > Can you tell us which platform you are developing a client plugin for?

            I write one for Mac and Windows, well, it is not a real plugin, but a
            way to integrate it in you web pages.



            > > Why only send the domain, doesn't the complete Uri makes sence?
            >
            > The browser's security policy isn't granular enough to separate URIs
            > into separate security contexts, so it would be easy for a site to
            > spoof any URI within the page's a given domain by injecting script
            > tags into other pages. Also, in Firefox (for example) there are many
            > scenarios where a page has URI that does not specify a domain
            > (about:blank, or a javascript: URI) yet the page does have a domain
            > according to the browser.
            >

            What I thought was pages like aol.com/users/xxxx or
            t-online.de/home/xxxx. Where is the "domain" specified, I thought it
            will use the Web browsers location always, which in my mind is not
            speficic enough.

            Michael



            > To make this header match the browser's security policy, it would be
            > possible to set a header of the form scheme://domain:port (with no
            > path included), but I'm not sure whether this is necessary.
            >
            >



            --
            Best regards | Schöne Grüße
            Michael

            Microsoft MVP - Most Valuable Professional
            Microsoft MCAD - Certified Application Developer

            http://weblogs.asp.net/mschwarz/
            http://www.ajaxpro.info/

            Skype: callto:schwarz-interactive
            MSN IM: passport@...
          • Douglas Crockford
            I have updated the JSONRequest proposal, removing the Origin feature. I have been persuaded that it can encourage bad practice.
            Message 5 of 22 , Feb 13, 2009
            View Source
            • 0 Attachment
              I have updated the JSONRequest proposal, removing the Origin feature.
              I have been persuaded that it can encourage bad practice.

              http://json.org/JSONRequest.html
            • pigwin32
              ... This question may have been asked previously but a quick search didn t turn up anything. Why does JSONRequest only support GET/POST and propose a new
              Message 6 of 22 , Feb 16, 2009
              View Source
              • 0 Attachment
                --- In json@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
                >
                > I am proposing a new mechanism for doing data transport in Ajax/Comet
                > applications. It is called JSONRequest. It is a minimal communications
                > facility that can be exempted from the Same Origin Policy.
                >
                > You can read about it here: http://json.org/JSONRequest.html
                >

                This question may have been asked previously but a quick search didn't
                turn up anything. Why does JSONRequest only support GET/POST and
                propose a new CANCEL request? What of PUT and DELETE? I can see how
                JSONRequest would be extremely useful for RESTful web services and I'm
                curious as to why you are proposing yet another protocol on top of
                HTTP when HTTP already provides the necessary verbs and
                exceptions/error codes. Wouldn't it be expedient to work within the
                existing HTTP specification? My apologies if this has already been
                addressed, I've arrived a little bit late to the discussion.

                - Dave
              • Tatu Saloranta
                ... I am not a REST expert, but isn t PUT used to store given payload (in this case, request in form of Json), and DELETE just ignore payload? Meaning that
                Message 7 of 22 , Feb 16, 2009
                View Source
                • 0 Attachment
                  On Mon, Feb 16, 2009 at 12:10 AM, pigwin32 <pigwin32@...> wrote:
                  > --- In json@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
                  >>
                  >> I am proposing a new mechanism for doing data transport in Ajax/Comet
                  >> applications. It is called JSONRequest. It is a minimal communications
                  >> facility that can be exempted from the Same Origin Policy.
                  >>
                  >> You can read about it here: http://json.org/JSONRequest.html
                  >>
                  >
                  > This question may have been asked previously but a quick search didn't
                  > turn up anything. Why does JSONRequest only support GET/POST and
                  > propose a new CANCEL request? What of PUT and DELETE? I can see how
                  > JSONRequest would be extremely useful for RESTful web services and I'm
                  > curious as to why you are proposing yet another protocol on top of
                  > HTTP when HTTP already provides the necessary verbs and
                  > exceptions/error codes. Wouldn't it be expedient to work within the
                  > existing HTTP specification? My apologies if this has already been
                  > addressed, I've arrived a little bit late to the discussion.

                  I am not a REST expert, but isn't PUT used to store given payload (in
                  this case, request in form of Json), and DELETE just ignore payload?
                  Meaning that such operations via JSONRequest wouldn't make much sense;
                  after all, you can call PUT with appropriate content type anyway, and
                  DELETE wouldn't require one.

                  That is: what would be useful semantics for such operations? (same
                  could be asked of GET -- but I assume that's for manual testing via
                  browser)

                  I guess case could be made that for completeness sake these verbs
                  should be supported.

                  -+ Tatu +-
                • Fang Yidong
                  Hello Tatu, While I was googling JSON.simple usage, I occasionally find JsonSimpleDriver.java in svn of codehaus, and the benchmark results, comparing with
                  Message 8 of 22 , Feb 19, 2009
                  View Source
                  • 0 Attachment
                    Hello Tatu,

                    While I was googling JSON.simple usage, I occasionally find JsonSimpleDriver.java in svn of codehaus, and the benchmark results, comparing with Jackson and other libraries. I think that it's your work?

                    The throughput of Jackson is high definitely and I really think Jackson is an excellent StAX JSON parser.

                    I am writing to you because I'd like to share some of my opinions on the testing itself. I know that you haven't pulished the results yet, here's just some discussions.

                    Here's my opinions:
                    1. I think different libraries accept different inputs, such as a byte array, a string, a inputstream or a reader, so the preparation of such input objects should be prepared in the warm up stage, not the running.

                    2. I think the iteration of the resulting graph is not a part of the parser and should not be put in the run method, but some minor operations can be performed to verified that the result is a correct one.

                    3. Could you also help to test the SAX-like interface of JSON.simple in the way of JacksonDriverStreaming.java did? 

                    I think your work will definitely help to improve the qualities of all JSON libraries.

                    Thanks.

                    Yidong Fang




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

                    [Non-text portions of this message have been removed]
                  • Fang Yidong
                    Sorry this message is intended to send to Tatu only. My bad. Since the result is not published yet, let s discuss it privately. Hello Tatu, While I was
                    Message 9 of 22 , Feb 19, 2009
                    View Source
                    • 0 Attachment
                      Sorry this message is intended to send to Tatu only. My bad.
                      Since the result is not published yet, let's discuss it privately.












                      Hello Tatu,



                      While I was googling JSON.simple usage, I occasionally find JsonSimpleDriver. java in svn of codehaus, and the benchmark results, comparing with Jackson and other libraries. I think that it's your work?



                      The throughput of Jackson is high definitely and I really think Jackson is an excellent StAX JSON parser.



                      I am writing to you because I'd like to share some of my opinions on the testing itself. I know that you haven't pulished the results yet, here's just some discussions.



                      Here's my opinions:

                      1. I think different libraries accept different inputs, such as a byte array, a string, a inputstream or a reader, so the preparation of such input objects should be prepared in the warm up stage, not the running.



                      2. I think the iteration of the resulting graph is not a part of the parser and should not be put in the run method, but some minor operations can be performed to verified that the result is a correct one.



                      3. Could you also help to test the SAX-like interface of JSON.simple in the way of JacksonDriverStream ing.java did? 



                      I think your work will definitely help to improve the qualities of all JSON libraries.



                      Thanks.



                      Yidong Fang




















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

                      [Non-text portions of this message have been removed]
                    • Tatu Saloranta
                      ... Hi there! Yes, that is true. ... Sure, thank you for your input. I hadn t yet published it, but it is of course public from the blog. ... Hmmh. I don t
                      Message 10 of 22 , Feb 19, 2009
                      View Source
                      • 0 Attachment
                        On Thu, Feb 19, 2009 at 11:08 PM, Fang Yidong <fangyidong@...> wrote:
                        > Hello Tatu,
                        >
                        > While I was googling JSON.simple usage, I occasionally find JsonSimpleDriver.java in svn of codehaus, and the benchmark results, comparing with Jackson and other libraries. I think that it's your work?

                        Hi there! Yes, that is true.

                        >
                        > The throughput of Jackson is high definitely and I really think Jackson is an excellent StAX JSON parser.
                        >
                        > I am writing to you because I'd like to share some of my opinions on the testing itself. I know that you haven't pulished the results yet, here's just some discussions.

                        Sure, thank you for your input. I hadn't yet published it, but it is
                        of course public from the blog.

                        >
                        > Here's my opinions:
                        > 1. I think different libraries accept different inputs, such as a byte array, a string, a inputstream or a reader, so the preparation of such input objects should be prepared in the warm up stage, not the running.

                        Hmmh. I don't think I fully agree, but I agree in that it depends on use case.

                        For me, the use case is always getting Json from an external source
                        (network request, from file system), and hence input is naturally a
                        stream of bytes. So if a library just takes a String, it must be
                        constructed from bytes.
                        I did give shortcuts for some parsers so that there was no need to
                        read from the stream, so in a way some parsers benefited from the
                        setup (from my perspective).

                        It is possible that other use cases could be ones where a String would
                        be needed anyway (like perhaps reading it from a DB), but for me this
                        is not the case.

                        > 2. I think the iteration of the resulting graph is not a part of the parser and should not be put in the run method, but some minor operations can be performed to verified that the result is a correct one.

                        I think needs to be, because otherwise you can not do anything of use;
                        and parsers could optimize away some processing.
                        I don't think results would differ a lot though, most parsers do
                        handle all the data independent of traversal. I can probably make this
                        configurable to see what the difference is.

                        > 3. Could you also help to test the SAX-like interface of JSON.simple in the way of JacksonDriverStreaming.java did?

                        Ah yes. Apologies for not trying it out -- I forgot that json.simple
                        does in fact have a streaming interface. I can add that, and make it
                        the main interface.

                        > I think your work will definitely help to improve the qualities of all JSON libraries.

                        Thank you, and thanks for feedback!

                        -+ Tatu +-
                      • Tatu Saloranta
                        ... (took the discussion offline, but if anyone is interested in what results we are discussing, those are at:
                        Message 11 of 22 , Feb 20, 2009
                        View Source
                        • 0 Attachment
                          On Thu, Feb 19, 2009 at 11:14 PM, Fang Yidong <fangyidong@...> wrote:
                          > Sorry this message is intended to send to Tatu only. My bad.
                          > Since the result is not published yet, let's discuss it privately.

                          (took the discussion offline, but if anyone is interested in what
                          results we are discussing, those are at:

                          http://www.cowtowncoder.com/blog/archives/2009/02/entry_204.html

                          I will be making some updates; and if any owners of other packages
                          have suggestions, let me know as well. Benchmarks are hard to do well
                          with different use cases and emphasis, so at least I want to document
                          presumptions and biases.

                          -+ Tatu +-
                        Your message has been successfully submitted and would be delivered to recipients shortly.