[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] tnetstrings.lua 1.0.0
- From: Josh Simmons <simmons.44@...>
- Date: Mon, 6 Jun 2011 00:34:43 +1000
On Mon, Jun 6, 2011 at 12:12 AM, Josh Simmons <simmons.44@gmail.com> wrote:
> On Mon, Jun 6, 2011 at 12:03 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
>> You could use escaping or some form of chunking for strings, then the
>> length does not need to be known up-front. It's more important for
>> tables, though, and there you could work with begin and end markers,
>> instead of encoding the length of the encoded string.
I toyed with the idea of having a protocol that was append only, so we
could have a single buffer and just write to it as we go. The problem
is you loose all the advantages of explicit lengths, namely
predictability in parsing.
>> One thing about netstrings that bothers me is that they appear to be
>> human-readable (mainly because ASCII data results in an ASCII string
>> after encoding, and there is a total redundant end separator), but you
>> cannot easily change them.
>
To expand on this too, it's not designed to be human readable, it's
designed to be easy to parse in many languages. This meant a text
protocol was the best choice. It's pretty readable as a side effect of
that, but it's not supposed to ever be edited by hand. The end marker
is semi-redundant, as well as marking the type it does give crude
sanity checking to the protocol. If you find a colon with a number
before it, then skip to the end and find a tns type marker then it's
pretty likely you're not parsing total gunk. It's also there for
backwards compatibility reasons, tns is backwards compatible with
netstrings.