On Thu, Mar 17, 2016 at 1:41 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: > > > 1. Debugging errors: > > I found debugging errors that happen in a consumer to be *really* > difficult -- errors mostly presented as things just silently not working. > It took a ton of messing around with logging setups before I could get > anything of use dumped to the console. This isn't strictly a Channels issue > (I've noted similar problems with AJAX views and errors in Celery tasks), > but I think Channels sorta brings the issue to a head. > > I think we need some better defaults, and simple, clear documentation, to > make sure that exceptions go somewhere useful. >
Yes, this is definitely an issue - right now, they pretty much only log to stdout. I would like to at least: a) Tie consumer errors into the same email-dispatch system for ADMINS as view errors, by default b) Write better docs about how to handle errors in a channels-like scenario, and what they present as (as you said, generally just a lack of response, like most networking code errors) > > 2. Static files: > > I had trouble getting static files served. I'm used to using Whitenoise ( > http://whitenoise.evans.io/en/stable/) for small-to-medium-ish sites that > don't need a proper static server, but of course it doesn't work with > Channels since Channels doesn't use WSGI! I found the (undocumented) > StaticFilesConsumer ( > https://github.com/jacobian/channels-example/blob/master/chat/routing.py#L5-L8), > but that feels less than ideal. > > I think this might be an opportunity, however. If Daphne learns how to > serve static files (perhaps via optional integration with Whitenoise?), > this would actually make static media in Django a bit easier by default. > > [I would be happy to work on this if I get a thumbsup.] > The static files consumer thing is merely for runserver, to match the capabilities of the existing WSGI one. We could take it further and make it an official public API, or work on something more reusable, or use whitenoise. It's worth noting that you can wrap ASGI consumers in something approaching middleware inside Django - that's what StaticFilesConsumer does to ViewConsumer - so maybe we should consider making this a more formal thing and having a nice API for applying them. > > 3. WebSocket routing: > > Channels routes all WebSocket connections to a single set of consumers > (the `websocket.*` consumers). This means that if you want multiple > WebSocket URLs in a single app you need to manually parse the path. And, to > make things more complicated, you only get the WebSocket path passed in the > connection message, so you have to also use a channel session to keep track. > > This feels like a distinct step back from the URL routing we already have > in Django, and it was surprising to me to have to do this by hand. It > definitely felt like Channels is missing some sort of WebSocket URL router. > > I had a brief chat with Andrew, who indicates that he'd planned for this > to be a post-1.0 feature. I'm not sure I agree - it feels pretty > fundamental - but I'd like to hear other thoughts. > > So, Florian's idea above is interesting, but unfortunately puts the HTTP-like parts at the outer level, which means it makes no sense for someone doing routing from something like a WAMP or SMS protocol server (to pick two protocols people might implement at some point). The idea I had in my head looked more like this: consumers = { 'sms.receive': incoming_sms, 'websocket.connect': UrlRouter( url("^$", root_ws_connect), url("^chat/([^/]+)/$", chat_ws_connect), ), 'websocket.receive': UrlRouter( url("^$", root_ws_receive), url("^chat/", chat_ws_receive), ), } Where UrlRouter is a class that you configure with URLs the same way views are done, and then its __call__ merely passes the message down to the right consumer. But yes, we do need this. Andrew -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFwN1uoBX7SRPkyzyzR4p220LUj1L0%2BYnse6%3D%3Di8o2Tp_9gsbQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
