Django namespace class decorator magic and intent

[daemonburrito]

I have been working on using gevent-socketio for an existing django application. At first, using the latest version in pypi, I hand-rolled integration; but then, I looked closer at 0.3.6 and the django_chat app, and I found the more elegant solution in gevent.socketio.sdjango.

I am having trouble with using it, though. I think the problem is mine; django_chat works fine, even with a "backported" version of gevent.sdjango (urls.defaults for django 1.3).

So the example works fine, and my use doesn't, somehow. I'm getting no_such_namespace, though there is a socket connection. Inspecting the socket.io client, it is also configured with the correct namespace.

I think the gap is my understanding of the namespace class decorator magic and its intent. I've scoured and grep'd the django_chat example to death, and it appears that the mere act of importing the ChatNamespace registers it with the SOCKETIO_NS global.

Is this not correct? What am I missing?

tl;dr: Explanation for gevent.socketio.sdjango needed.

Will volunteer to write docs with answer.

[daemonburrito]

Answering some of my own questions:

The namespace class decorator appears to be working as designed. The value of SOCKETIO_NS in call is

{'/foo': <class 'myapp.socketio.namespaces.FooNamespace'>}

However, the value of SOCKETIO_NS in the socketio view function is always

{}

[wuzuf]

I wrote this file, but with the information you provided, it is hard to see what is wrong. Can I access your code somewhere? The way you describe it, it looks to me that you have to instances of this SOCKETIO_NS dict in your process, but I can't tell how you end up like this. Honestly, I am not very proud of this global. Maybe we could instead register the namespaces in a django object, like the config, that I am sure we can access from everywhere.

Re-reading your question, I may have an idea. You say you "backported" the sdjango file. Does it mean you have a copy in your own repo? If so, you probably register your namespace in your own copy while socketio will continue to look in the socketio repo.

I think the solution to your problem might be to update sdjango.py in socketio to have it work with django 1.3. (I can help if needed)

[daemonburrito]

That is very interesting. I bet you're right; my sdjango.py is separate, and may be being clobbered by socketio's later on.

Unfortunately, it is a private repo. But I can share my "backport", for sure. It's trivial:

from django.conf.urls.defaults import patterns, url, include

instead of:

from django.conf.urls import patterns, url, include

I feel a little silly asking for 1.3 support with the 1.5 rc having been released. I can make a fork with a silly hack like a try/except for the import. Whether that's too ugly can be your decision.

I will try it out and let you know if you're right, and send a pull request.

[daemonburrito]

@wuzuf You were right. I also like the idea of a registry for django, but I don't know how much I can do for you there. I really like your class decorator approach, and that's something I probably wouldn't have come up with on my own. Your Python skills are obviously better than mine.

I wrote it against abourget's tree, because yours was a bit behind. Please feel free to comment there if you have any thoughts.

[youen]

I fix the empty SOCKETIO_NS inspired by the Django admin site source code [1]. An autodiscover function call in the urls.py of the project load sockets.py modules of each django application installed. Then the Namespace class is registered in the SOCKETIO_NS dictionary.

The filename sockets.py is a protocol to use this feature.

I update the django chat example too.

[1] https://github.com/django/django/blob/master/django/contrib/admin/init.py

[fcurella]

If this pull request gets accepted, I think the filename to be discoverable should be more specific, like 'socketio.py'. People may need to use a filename called 'sockets.py' for something else than socket.io

On Feb 9, 2013, at 5:36 PM, Youen Péron [email protected] wrote:

I fix the empty SOCKETIO_NS inspired by the Django admin site source code [1]. An autodiscover function call in the urls.py of the project load sockets.py modules of each django application installed. Then the Namespace class is registered in the SOCKETIO_NS dictionary.

The filename sockets.py is a protocol to use this feature.

I update the django chat example too.

[1] https://github.com/django/django/blob/master/django/contrib/admin/init.py

— Reply to this email directly or view it on GitHub..

[youen]

Yes, the filename is a convention that should get discussed.

+1 for 'socketio.py'

On Sun, Feb 10, 2013 at 4:51 PM, Flavio Curella [email protected]:

If this pull request gets accepted, I think the filename to be discoverable should be more specific, like 'socketio.py'. People may need to use a filename called 'sockets.py' for something else than socket.io

On Feb 9, 2013, at 5:36 PM, Youen Péron [email protected] wrote:

I fix the empty SOCKETIO_NS inspired by the Django admin site source code [1]. An autodiscover function call in the urls.py of the project load sockets.py modules of each django application installed. Then the Namespace class is registered in the SOCKETIO_NS dictionary.

The filename sockets.py is a protocol to use this feature.

I update the django chat example too.

[1] https://github.com/django/django/blob/master/django/contrib/admin/init.py

— Reply to this email directly or view it on GitHub..

— Reply to this email directly or view it on GitHubhttps://github.com/abourget/gevent-socketio/issues/118#issuecomment-13351685..

Youen Péron

[abourget]

Please read invitation to Wednesday September 18th's sprint: https://groups.google.com/forum/#!topic/gevent-socketio/2OIRKA8M2uE