tornado 3.x seems to have broken json encoding:

[thebookworm101]

this is what i get on the terminal with the dailyscrum example when the browser connects:

[E 130705 23:57:43 web:1121] Uncaught exception POST /dailyscrum/admin (::1)
    HTTPRequest(protocol='http', host='localhost:8081', method='POST', uri='/dailyscrum/admin', version='HTTP/1.1', remote_ip='::1', body=b'{"key":null,"collab":true,"cacheState":true,"requesturl":"localhost:8081/dailyscrum/index.html","sessionName":""}', headers={'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8', 'Cookie': 'BAYEUX_BROWSER=ea33-7xo38l7c00n0hhuzn0uh1a9f; coweb.auth.public.username="dXNlcjAwMA==|1373056996|5912e235b60467e6c31ef2dc8a15377905c17523"', 'Host': 'localhost:8081', 'Accept-Language': 'en-US,en;q=0.5', 'Accept-Encoding': 'gzip, deflate', 'Cache-Control': 'no-cache', 'Content-Type': 'application/json;charset=UTF-8', 'User-Agent': 'Mozilla/5.0 (X11; Linux i686; rv:20.0) Gecko/20100101 Firefox/20.0', 'Content-Length': '113', 'Referer': 'http://localhost:8081/dailyscrum/index.html', 'Connection': 'keep-alive', 'Pragma': 'no-cache'})
    Traceback (most recent call last):
      File "/home/mike/eng/coweb/coenv/lib/python3.3/site-packages/tornado/web.py", line 1077, in _execute
        *self.path_args, **self.path_kwargs)
      File "/home/mike/eng/coweb/coenv/lib/python3.3/site-packages/tornado/web.py", line 1892, in wrapper
        return method(self, *args, **kwargs)
      File "/home/mike/eng/coweb/coenv/lib/python3.3/site-packages/coweb/admin.py", line 84, in post
        self.write(resp)
      File "/home/mike/eng/coweb/coenv/lib/python3.3/site-packages/tornado/web.py", line 517, in write
        chunk = escape.json_encode(chunk)
      File "/home/mike/eng/coweb/coenv/lib/python3.3/site-packages/tornado/escape.py", line 75, in json_encode
        return json.dumps(value).replace("</", "<\\/")
      File "/usr/lib/python3.3/json/__init__.py", line 226, in dumps
        return _default_encoder.encode(obj)
      File "/usr/lib/python3.3/json/encoder.py", line 187, in encode
        chunks = self.iterencode(o, _one_shot=True)
      File "/usr/lib/python3.3/json/encoder.py", line 245, in iterencode
        return _iterencode(o, 0)
      File "/usr/lib/python3.3/json/encoder.py", line 169, in default
        raise TypeError(repr(o) + " is not JSON serializable")
    TypeError: b'user000' is not JSON serializable
[E 130705 23:57:43 web:1514] 500 POST /dailyscrum/admin (::1) 132.92ms

seems like a python 2x - 3x issue:
See the same error with python 3.30 reproduced on the terminal:

Python 3.3.0 (default, Sep 29 2012, 22:33:28)
[GCC 4.7.2 20120921 (Red Hat 4.7.2-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import json
>>> a = b'user000'
>>> b = json.dumps(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.3/json/__init__.py", line 226, in dumps
    return _default_encoder.encode(obj)
  File "/usr/lib/python3.3/json/encoder.py", line 187, in encode
    chunks = self.iterencode(o, _one_shot=True)
  File "/usr/lib/python3.3/json/encoder.py", line 245, in iterencode
    return _iterencode(o, 0)
  File "/usr/lib/python3.3/json/encoder.py", line 169, in default
    raise TypeError(repr(o) + " is not JSON serializable")
TypeError: b'user000' is not JSON serializable

But the same works fine on python 2.7.3

Python 2.7.3 (default, Jul 24 2012, 10:05:38) 
[GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = b'user000'
>>> import json 
>>> c = json.dumps(a)
>>> c
'"user000"'

---

edit changed the issue title from:
python 3.3.0 seems to have broken json encoding:
to
tornado 3.x . seems to have broken json encoding:

[ccotter]

I just reproduced this, I'll look into it further

[ccotter]

This is more related to Tornado 2.4 vs 3 changes. The python coweb server works with Tornado 2.4, but apparently not Tornado 3. Part of the issue was not converting tornado.web.RequestHandler.current_user to a utf-8 string with decode. Even after I fixed that, the server would connect (your issue went away), but I could not get the coedit demo to communicate with 2+ users. For now, we will have to stick with Tornado 2.4 and disallow Tornado 3 until all related issues are figured out.

This fix (and whether or not Tornado 3 issues are fixed) will go into the next release, so in the meantime, you will need to clone the git repo and install the server from the master branch.

You can follow these steps with a few exceptions. After cloning the coweb repo, at step 5, you will need to navigate to coweb/servers/python and run pip install .. This will install the code from master. Then, you can deploy a cowebx demo with pycoweb. I would recommend coedit or comap instead of the dailyscrum demo.

[thebookworm101]

@ccotter thanks for checking it out,
as i was playing with it i changed
this

     81             'info': sessionInfo,
     82             'username' : username
     83         }
     84         self.write(resp)

to this (watch line 82)

     81             'info': sessionInfo,
     82             'username' : username.decode()
     83         }
     84         self.write(resp)

in servers/python/coweb/admin.py

and the first client seems to connect fine, but a second client can not join that session (there's some place in the code thats tripping and i still dont get the flow of the code so im having a hard time debugging).

[ccotter]

5822afa is the commit

[thebookworm101]

ok,
it works with tornado 2.4.1, if you have some pointers on where to look i could try to find out whats breaking.

[ccotter]

@thebookworm101
I can't really give much guidance on where to look; the only guess I can give is the second client is having trouble with the joining protocol (obviously). http://opencoweb.org/ocwdocs/protocol/coweb_bayeux.html might be a good place to start.

I'll do some digging and see what I can find. As always, if you find anything, feel free to submit a pull request :)

[thebookworm101]

@ccotter I submitted the pull request for this, but i noticed that if i were to paste more than 7 lines of text into a collaborative session, it either takes too long to sync or disconnects the session and the page refreshes. Is there some plan to deal with situations like that? How possible is it right now to change from one character at a time when pasting content to a set of characters at a time (or all thats pasted if its not too big). This problem exists even with the current setup. (try pasting >7 lines of text on the dailyscrum textarea in the demo.) The problem imho is that either

1. 7 lines of text seems too much for the session (feels like DDOS?) or

2. The op engine underneath is overwhelmed by rapid fire additions.
   I honestly dont understand the insides so well, so that's my two pence.