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

Re: [json] Re: JSON.hpack - JavaScript, PHP, C# (Python Soon)

Expand Messages
  • Tatu Saloranta
    On Thu, May 28, 2009 at 1:25 AM, an_red@ymail.com ... Yes, certainly, not arguing with that, wrt. speed. ... No doubt, it should be a fairly simple
    Message 1 of 8 , May 28, 2009
    • 0 Attachment
      On Thu, May 28, 2009 at 1:25 AM, an_red@...
      <andrea.giammarchi@...> wrote:
      > Tatu, gzip works faster in any case over JSON.hpack(ed) stuff for the same reason JSON.stringify / parse is faster over JSON.hpacked stuff, less characters to work over (you gzip a string smaller up to 80%)

      Yes, certainly, not arguing with that, wrt. speed.

      > It could be a separated layer in any case, but even over, will be faster. The C# implementation of both hpack and hunpack are extremely fast, I need time to create a Python version and I was planning to create a PHP

      No doubt, it should be a fairly simple transformation on other
      languages as well.

      > extension in C as well but only one Java guy told me he will try to create a parser ... I mean, C# version is not that different, I guess a porting will take a

      There are many good fast Java parsers, so I would recommend using one
      of those, and add transformation layer on top. No need to write a
      parser (IMO -- but I have written mine so I may be biased).

      > Anyway, I miss your point about specify the convention ... do you mean
      > proper specs? I could write something more than I already wrote on github homepage, let me know.

      Yeah, specification of this convention (or transformation),
      documenting how it should behave. This is necessary (or at least
      useful) to ensure interoperability. Given how many people want to
      write their own json parsers (... just a random example...), because
      they don't like what is available, I'm sure there'll be many who'd
      want to reimplement this mapping as well.
      But at least implementations would be interoperable.

      So yes, need not be anything too heavy-weight, but somewhat formal
      notation helps in my opinion.

      Thanks!

      -+ Tatu +-
    • an_red@ymail.com
      Is something like this enough? http://wiki.github.com/WebReflection/json.hpack/specs-details Best Regards. Andrea Giammarchi
      Message 2 of 8 , May 29, 2009
      • 0 Attachment
        Is something like this enough?
        http://wiki.github.com/WebReflection/json.hpack/specs-details

        Best Regards.

        Andrea Giammarchi

        --- In json@yahoogroups.com, Tatu Saloranta <tsaloranta@...> wrote:
        >
        > On Thu, May 28, 2009 at 1:25 AM, an_red@...
        > <andrea.giammarchi@...> wrote:
        > > Tatu, gzip works faster in any case over JSON.hpack(ed) stuff for the same reason JSON.stringify / parse is faster over JSON.hpacked stuff, less characters to work over (you gzip a string smaller up to 80%)
        >
        > Yes, certainly, not arguing with that, wrt. speed.
        >
        > > It could be a separated layer in any case, but even over, will be faster. The C# implementation of both hpack and hunpack are extremely fast, I need time to create a Python version and I was planning to create a PHP
        >
        > No doubt, it should be a fairly simple transformation on other
        > languages as well.
        >
        > > extension in C as well but only one Java guy told me he will try to create a parser ... I mean, C# version is not that different, I guess a porting will take a
        >
        > There are many good fast Java parsers, so I would recommend using one
        > of those, and add transformation layer on top. No need to write a
        > parser (IMO -- but I have written mine so I may be biased).
        >
        > > Anyway, I miss your point about specify the convention ... do you mean
        > > proper specs? I could write something more than I already wrote on github homepage, let me know.
        >
        > Yeah, specification of this convention (or transformation),
        > documenting how it should behave. This is necessary (or at least
        > useful) to ensure interoperability. Given how many people want to
        > write their own json parsers (... just a random example...), because
        > they don't like what is available, I'm sure there'll be many who'd
        > want to reimplement this mapping as well.
        > But at least implementations would be interoperable.
        >
        > So yes, need not be anything too heavy-weight, but somewhat formal
        > notation helps in my opinion.
        >
        > Thanks!
        >
        > -+ Tatu +-
        >
      • Tatu Saloranta
        On Fri, May 29, 2009 at 3:29 AM, an_red@ymail.com ... I think so (didn t read in detail) -- and if there are questions, it s easy to contact you and suggest
        Message 3 of 8 , May 29, 2009
        • 0 Attachment
          On Fri, May 29, 2009 at 3:29 AM, an_red@...
          <andrea.giammarchi@...> wrote:
          > Is something like this enough?
          > http://wiki.github.com/WebReflection/json.hpack/specs-details

          I think so (didn't read in detail) -- and if there are questions, it's
          easy to contact you and suggest clarifications.

          Thanks!

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