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

JSONRequest

Expand Messages
  • Douglas Crockford
    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
    Message 1 of 22 , Mar 11, 2006
    • 0 Attachment
      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
    • Michal Migurski
      ... Two comments, based on a quick initial read: 1) The timeout feels unnecessary, and potentially a hassle for debugging purposes. It should be left to lower
      Message 2 of 22 , Mar 11, 2006
      • 0 Attachment
        > 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

        Two comments, based on a quick initial read:

        1) The timeout feels unnecessary, and potentially a hassle for
        debugging purposes. It should be left to lower levels, and doesn't
        appear to introduce any additional security. Same goes for the
        content-length limitation. Both of these are going to be bumped into
        by some user, or omitted in some implementation, so specifying them
        is asking for trouble. Are they needed for the duplex mode described
        at bottom? Can the callback function specified in the JSONReq be
        called repeatedly upon multiple responses from the server, if it's
        intended for asynchronous server-push situations?

        2) I'm not comfortable with invoking scripts on a remote server when
        determining permissions levels. I've always felt that Flash has a
        good answer to this problem in the form of crossdomain policy files.
        Since a lot of servers already provide them, and they're just
        plaintext files in a predictable location, why not support them in
        the usual XHR functionality, too? Also, what about JSON-RPC? Ignoring
        these two existing pieces of the puzzle seems intuitively like a bad
        idea.

        I'm glad this problem is being addressed, though. I recently ran into
        the same security issues when working on http://
        backchannel.stamen.com, finding that XHR didn't even allow me to make
        requests of a different port on the same host. It was easy to add in
        a simple PHP proxy for this purpose, but obviously I would have
        preferred not to. Things will get very interesting when client-side
        apps can freely communicate with a range of servers at once.

        ----------------------------------------------------------------
        michal migurski- contact info and pgp key:
        sf/ca http://mike.teczno.com/contact.html





        [Non-text portions of this message have been removed]
      • Stefan Gössner
        Sounds really very interesting. 1. Is there a test implementation to play with? 2. What is the motivation behind the limitations of data size and nesting
        Message 3 of 22 , Mar 12, 2006
        • 0 Attachment
          Sounds really very interesting.

          1. Is there a test implementation to play with?
          2. What is the motivation behind the limitations of data size and
          nesting levels. Should that really go into the spec or isn't it rather
          an (perhaps recommended) implementation detail.
          3. Don't exactly understand the mechanism of duplex connections. Isn't
          it a Comet-like server push solution. I would like to see an example
          implementation here also.
        • Douglas Crockford
          ... Not yet, but I hope to make some announcements soon. ... It should go somewhere. I think there should be some limit other than whatever you can imagine .
          Message 4 of 22 , Mar 13, 2006
          • 0 Attachment
            > 1. Is there a test implementation to play with?

            Not yet, but I hope to make some announcements soon.

            > 2. What is the motivation behind the limitations of data size and
            > nesting levels. Should that really go into the spec or isn't it rather
            > an (perhaps recommended) implementation detail.

            It should go somewhere. I think there should be some limit other than
            "whatever you can imagine". Senders and receivers need some way of
            agreeing on what the limit is, so that we can distinguish long
            messages from exhaustion attacks.

            > 3. Don't exactly understand the mechanism of duplex connections. Isn't
            > it a Comet-like server push solution. I would like to see an example
            > implementation here also.

            That's the idea. By creating a channel for receiving messages from the
            server, the server can send whenever it has data available. This can
            provide much better performance than polling.
          • Douglas Crockford
            The JSONRequest does only one thing: It exchanges data between scripts on pages with JSON servers in the web. It provides this highly valuable service while
            Message 5 of 22 , Mar 17, 2006
            • 0 Attachment
              The JSONRequest does only one thing: It exchanges data between scripts
              on pages with JSON servers in the web. It provides this highly
              valuable service while introducing no new security vulnerabilities.

              A browser within a filewall may have the capability to interact with a
              server (penzance.org). Computers on the outside do not have that
              capability. Can a computer on the outside (pirate.net) cause a browser
              to act as its agent in interacting with an internal server?

              Current, XMLHttpRequest does not allow a script from a page from
              pirate.net to connect to penzance.org because of the Same Origin Policy.

              JSONRequest does allow the connection, but with some limitations:

              The method is POST
              The Content-Type is application/json.
              The POST body data will be in JSON format.
              The response data will be in JSON format.
              The character encoding in both directions will be UTF-8, strictly
              enforced.

              Does this allow improperly secured applications to be accessed?

              Application that are looking for GET cannot be accessed because
              JSONRequest only uses POST.
              Responses which are not JSON text will not be delivered to the
              requesting script.

              This is sufficient to protect most legacy applications.

              But what of legacy applications that accept POST. Could JSONRequest be
              used to improperly POST to these applications, thereby corrupting
              databases? JSONRequest mitigates this danger:

              The POST data is in JSON format, so as seen by conventional web
              applications, the first form field name will have a [" or {" prefix,
              which may cause a fault.

              Cookies and HTTP authentication are not sent.

              Contrast this to form.submit, which can send a conventional POST body
              and cookies and HTTP authentication. JSONRequest is more secure than
              the form.submit feature which is currently implemented everywhere. By
              switching to a policy of responding only to well-formatted
              JSONRequest, applications can be made more secure.

              When applications are designed to use JSONRequest, they can take
              advantage of the Domain HTTP header field which identifies the source
              of the page. This can be used to determine the origin of the page
              making the request, which can be useful to know when making access
              decisions.

              http://json.org/JSONRequest.html
            • zackthom
              Deos JSON Request allow a true POST today? I reviewed your docs, and there is some great information here, but you do not discuss how to do a POST without
              Message 6 of 22 , Apr 18, 2006
              • 0 Attachment
                Deos JSON Request allow a true POST today?

                I reviewed your docs, and there is some great information here, but you
                do not discuss how to do a POST without xmlHtpp.

                I am interested in a remote scripting call that allowes me to send
                HEADERS.

                Is this a proposed new standard or a library implmentation? How can I
                test it?
              • John David Duncan
                Hi, I m interested in implementing the server side of JSONRequest, and I m a bit confused by the JSONRequest.get description in the proposal. The sample server
                Message 7 of 22 , Sep 22, 2007
                • 0 Attachment
                  Hi,

                  I'm interested in implementing the server side of JSONRequest, and
                  I'm a bit confused by the JSONRequest.get description in the proposal.

                  The sample server response says:

                  HTTP/1.1 200 OK
                  Content-Type: application/jsonrequest
                  Content-Length: xxxx
                  JSONRequest: 6

                  What is the "JSONRequest: 6" header? Is 6 the request serial number?
                  (and if so, how did the server get the serial number from the client?)

                  Thanks,

                  JD
                • Douglas Crockford
                  ... The current proposal can be found at http://json.org/JSONRequest.html
                  Message 8 of 22 , Sep 22, 2007
                  • 0 Attachment
                    --- In json@yahoogroups.com, John David Duncan <john.david.duncan@...>
                    wrote:

                    > I'm interested in implementing the server side of JSONRequest, and
                    > I'm a bit confused by the JSONRequest.get description in the proposal.

                    The current proposal can be found at http://json.org/JSONRequest.html
                  • John David Duncan
                    ... Yep, that s the one I m referring to. Is the JSONRequest header supposed to be there, in this response? HTTP/1.1 200 OK Content-Type:
                    Message 9 of 22 , Sep 22, 2007
                    • 0 Attachment
                      >
                      >> I'm interested in implementing the server side of JSONRequest, and
                      >> I'm a bit confused by the JSONRequest.get description in the
                      >> proposal.
                      >
                      > The current proposal can be found at http://json.org/JSONRequest.html

                      Yep, that's the one I'm referring to. Is the "JSONRequest" header
                      supposed to be there, in this response?


                      HTTP/1.1 200 OK
                      Content-Type: application/jsonrequest
                      Content-Length: xxxx
                      JSONRequest: 6



                      JD
                    • Douglas Crockford
                      ... I see what you mean. No, that isn t supposed to be there. I have corrected it. Thank you.
                      Message 10 of 22 , Sep 22, 2007
                      • 0 Attachment
                        --- In json@yahoogroups.com, John David Duncan <john.david.duncan@...>
                        wrote:
                        > Is the "JSONRequest" header
                        > supposed to be there, in this response?
                        >
                        >
                        > HTTP/1.1 200 OK
                        > Content-Type: application/jsonrequest
                        > Content-Length: xxxx
                        > JSONRequest: 6

                        I see what you mean. No, that isn't supposed to be there.
                        I have corrected it. Thank you.
                      • John David Duncan
                        ... Thanks! I have one more thought about the proposal. The Firefox plugin chooses to send an Accept: application/ jsonrequest header with the request, and
                        Message 11 of 22 , Oct 10, 2007
                        • 0 Attachment
                          On Sep 22, 2007, at 8:27 PM, Douglas Crockford wrote:

                          >> Is the "JSONRequest" header
                          >> supposed to be there, in this response?
                          >> ...
                          > I see what you mean. No, that isn't supposed to be there.
                          > I have corrected it. Thank you.


                          Thanks! I have one more thought about the proposal.

                          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.


                          JD
                        • Douglas Crockford
                          ... You re right.
                          Message 12 of 22 , Oct 11, 2007
                          • 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 13 of 22 , Oct 14, 2007
                            • 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 14 of 22 , Oct 14, 2007
                              • 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 15 of 22 , Oct 14, 2007
                                • 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 16 of 22 , Feb 13, 2009
                                  • 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 17 of 22 , Feb 16, 2009
                                    • 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 18 of 22 , Feb 16, 2009
                                      • 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 19 of 22 , Feb 19, 2009
                                        • 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 20 of 22 , Feb 19, 2009
                                          • 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 21 of 22 , Feb 19, 2009
                                            • 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 22 of 22 , Feb 20, 2009
                                              • 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.