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

1262Re: JSON.hpack - JavaScript, PHP, C# (Python Soon)

Expand Messages
  • an_red@ymail.com
    May 28, 2009
    • 0 Attachment
      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%)

      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 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 couple of hours and nothing else.

      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.

      Regards

      --- In json@yahoogroups.com, Tatu Saloranta <tsaloranta@...> wrote:
      >
      > On Wed, May 27, 2009 at 6:27 AM, Andrea Giammarchi
      > <andrea.giammarchi@...> wrote:
      > > (it was a direct message, I have copied and pasted here as well)
      > > Good afternoon Mr Douglas Crockford,
      > > I wonder if you have seen already my latest JSON related project, called
      > > JSON.hpack,
      > > an Homogeneous Collection Packer.
      > >
      > > As summary, hpack transform a JSON list of objects, usually a database
      > > resultSet
      > > [{name:value},{name:value},{name:value}]
      > > into an array only collection with columns info in the special index 0
      >
      > This seems like a simple and possibly sensible convention.
      > But in addition to having an implementation, it would seem most
      > interesting to specify the convention. This would allow
      > implementations for other languages: verbosity of textual data formats
      > matters for many use cases, and json is being used a lot on
      > server-to-server communication too.
      >
      > Wrt compression: I am sure gzip would yield more additional
      > compression, since it would not only eliminate redundancy wrt. names
      > (which compress very well obviously) but also for values. It can
      > definitely be added as a separate layer.
      > But given how CPU hungry gzip is (see
      > [http://www.cowtowncoder.com/blog/archives/2009/05/entry_263.html%5d for
      > example; for java json, overhead is 3x - 5x basic processing),
      > conventions can help a lot, so the two can be complementary; even if
      > plain gzip would probably compress things more if size reduction was
      > the only goal.
      >
      > -+ Tatu +-
      >
    • Show all 8 messages in this topic