no web-readable docs and examples

[GoogleCodeExporter]

It would really help to get an overview of the RSON in web readable format 
for comparison with others instead of downloading PDF.

Original issue reported on code.google.com by techtonik@gmail.com on 15 Mar 2010 at 9:17

[GoogleCodeExporter]

Used wikir to convert manual to wiki markup and slapped it up there.

Still not great, but it's a start :-)

Original comment by pmaupin on 21 Mar 2010 at 8:17

• Changed state: Accepted

[GoogleCodeExporter]

Now it is indeed more clear, but I would say examples are a bit biased. For 
example:

-- cut --
1
2
3
Results in the following equivalent JSON:

[
  1,
  2,
  3
]
-- cut --
It is evident that JSON alternative would be [1,2,3]

"Any valid JSON file is also a valid RSON file" - does that mean that parsers 
should 
support both formats?

The page doesn't list format shortcoming. It looks like the format is flawless, 
but 
nobody will believe that. People will blame your format if you did not warned 
them 
about problems. For example, speed - JSON parsers don't care about line endings 
or 
quoting outside of strings, so JSON should be faster, because RSON is JSON with 
additional processing. JSON is also native JavaScript format - you do not need 
anything to parse JSON there, but for RSON you'll have to write a parser. I 
haven't 
used any parsers in JavaScript, and I doubt they would be efficient.

Original comment by techtonik@gmail.com on 23 Mar 2010 at 6:00

[GoogleCodeExporter]

"Now it is indeed more clear, but I would say examples are a bit biased. For 
example:
...
"

Well, you see, I just can't win.  In the original version of the PDF manual 
that you
didn't want to read, the examples were as you describe, but somebody complained 
about
that:

http://groups.google.com/group/rson-discuss/msg/9aaec8c7f3a67f3f

So, instead of just dumping the objects, I asked the dump function to dump them 
for
me in an indented format.  Anyway, anybody who knows JSON would know how it 
could be
rewritten, so I don't view it as "fair" or "unfair" -- it is just one possible
representation.  Yes, there are extra linefeeds in the examples, but that's just
whitespace -- JSON definitely requires those brackets and commas!  Anyway, if 
you DO
view it as "unfair", then RSON still doesn't lose, because you can write 
[1,2,3] in
RSON as well!

"Any valid JSON file is also a valid RSON file" - does that mean that parsers 
should 
support both formats?

If you view JSON as a separate format, sure.  But I view RSON as a superset of 
JSON,
so that was just making that clear.  You can (and probably will!) use JSON 
snippets
inside your RSON.

"I haven't used any parsers in JavaScript"

Well, as long as you know where your data is coming from, that's great.  
Otherwise...

But as far as shortcomings of the parser, that would be best discussed on the
rson-discuss google group, and then I will update the manual once a consensus is
reached.  Personally, I think it's pretty obvious that if you accept more ways 
of
doing things to make a file format more accomodating for humans, that will 
marginally
increase the parsing time.  However, I have to point out that on some of my test
data, the current RSON parser is FASTER than the current Python 2.6 json parser,
WHICH INCLUDES A C TOKENIZER!!!   The simplejson parser is faster than the RSON
parser, and the C version of that is really a lot faster, but the point is that 
RSON
can still be parsed in around the same time as JSON (assuming that you are 
actually
using a parser for JSON).  If you don't want to use a parser then sure, game 
over --
you won't be using RSON.

Anyway, for speed, the thing to compare RSON to is YAML.  That'll put your 
computer
to sleep.  In fact, the whole reason I designed RSON and wrote a parser is that 
the
pure Python YAML parser is way too slow.  So, for the purposes I designed RSON 
for,
no, I don't view speed as an issue.

Original comment by pmaupin on 23 Mar 2010 at 2:12

[GoogleCodeExporter]

Sounds reasonable. I certainly see advantage in unquoted strings and more human 
oriented format. Keep up with the spec - we might get something worthy in the 
end. You 
may want to create a syntax highlighting scheme for RSON for Colorer library 
http://colorer.sourceforge.net/

Original comment by techtonik@gmail.com on 23 Mar 2010 at 9:25