- Is something like this enough?
--- In email@example.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.
> -+ Tatu +-
- On Fri, May 29, 2009 at 3:29 AM, an_red@...
> Is something like this enough?I think so (didn't read in detail) -- and if there are questions, it's
easy to contact you and suggest clarifications.
-+ Tatu +-