Re: Feedback on Django Channels

On Fri, Mar 18, 2016 at 4:40 PM, Vincent wrote: > Hey Andrew, > > Thanks for looking through all that, and for the reply. > > I like the simplicity of your updated examples. I started to make a > counter-example to suggest that `include` be inside of a `route` ( > ht

Re: Feedback on Django Channels

tification.routing.routing"), ] It also means that the simple example case stays quite readable: routing = [ route("websocket.connect", ws_connect), route("websocket.receive", ws_receive), route("websocket.disconnect", ws_disconnect), ] We can also

Re: Feedback on Django Channels

plicated, 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 >

Re: Feedback on Django Channels

Yes, my intent is that "path" is just a stand-in for "any string key in a message", thus you could route other ways (for example, `method` in http.request, though that's probably not super useful inside Django). Andrew On Sat, Mar 19, 2016 at 1:40 PM, Vincent wrote:

Re: Feedback on Django Channels

way. I think include should never need a channel, and route should always need one - which means the router always knows that every entry has exactly one channel defined that can be matched against. Andrew On Fri, Mar 18, 2016 at 5:43 PM, Vincent wrote: > Andrew, > > Ah, excellent. I ju

Re: Feedback on Django Channels

You're right. Assume I put the keyword arguments at the end, sorry - the two positional arguments are the channel name and the consumer. On Fri, Mar 18, 2016 at 12:21 PM, Ryan Hiebert wrote: > > On Mar 18, 2016, at 9:58 AM, Andrew Godwin wrote: > > routing = [ >

Re: Feedback on Django Channels

or FileResponses to the main handling code rather than just Staticfiles, so it should be fine. 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 receiv

Re: Feedback on Django Channels

redis nodes into memory-only mode so that the data is never persisted, at least (channels doesn't need persistance beyond about a minute), but I can imagine a channel layer where you pass a symmetric encryption key in its configuration or similar. Andrew -- You received this message because

Re: Feedback on Django Channels

let people provide a regex to match against e.g. http.request and websocket.connect's `path` key. It's probably something we could pay for someone to work on for the "main" (Redis-backed) layer implementation? I could add it in too, but it's not as high priority as some other

Re: Feedback on Django Channels

. Andrew On Tue, Mar 22, 2016 at 2:24 PM, Jacob Kaplan-Moss wrote: > I do think encrypting the Redis channel layer is something we should > offer: Redis out of the box doesn't do transport-layer encryption, which is > going to make Channels a hard sell to anyone with any for of > regu

Re: Feedback on Django Channels

irements when I was dealing with HIPAA (and some other compliance > regulations) a few months ago. > > Alright, good to know. I'll put a task down in my notes for message encryption and we can add it to the list of things people can work on and get paid for when we put that up.

DjangoCon US 2016

ee the link above). Is cost a concern? Not a problem! Apply for financial aid (deadline April 25th). <https://2016.djangocon.us/financialaid> You can follow all the latest on Twitter <https://twitter.com/djangocon>. Hope to see you in Philly! Andrew -- You received this messa

Re: Feedback on Django Channels

On Fri, Apr 1, 2016 at 11:32 PM, Shai Berger wrote: > Hi, > > Finally found the time to go through this discussion. > > The first note that comes to mind is: > > Although it has already been pointed out more than once that positional > arguments cannot follow keyword arg

Re: Feedback on Django Channels

to change all the docs and examples to work this way - specifying "consumer=" as a kwarg will already work. I'm slightly concerned about forcing keyword-only, though. Andrew -- You received this message because you are subscribed to the Google Groups "Django develope

Re: Vendoring Select2

In previous projects (before moving to rolling my own UI components), I ended up favouring Selectize (http://selectize.github.io/selectize.js/) after getting fed up with Chosen and Select2 - but this was a few years ago and I can't remember my reasons. But if it hasn't been considered, it might be

Re: Django Integration

ms of things like making the enforce_ordering decorator a bit more efficient, but I see these as being entirely valid things to do after the feature freeze) Andrew On Tue, May 3, 2016 at 5:57 PM, Tim Graham wrote: > Hi Andrew, > > How are things going with the patch [0]? Do you think you

Re: Django Integration

aybe because we're declaring them as core dependencies (I patched in install_requires into setup.py for them) we should be very strict? If this patch is going to be denied based on Daphne not having sufficient test coverage then I suspect we'll miss the deadline and have to foist this

Re: Django Integration

ange I'm going to make, Django will depend on these in install_requires but not actually use them until you try and use a channels feature; they're in install_requires out of user convenience (having a traceback the first time you use the new built-in Django feature seems bad). Consideri

Re: Django Integration

he other option, but it seems to run contrary to Django's traditional batteries-included philosophy (and would result in some ugly, ugly import code in the channels modules). I'm curious to hear more opinions though, if there's support for it I'm happy to change it. Andrew -- You

Re: Django Integration

iate that I've spent a hell of a lot of time getting the project to this point, and anything missing is not because of malice or incompetence but because I don't believe that 100% test coverage is a necessary prerequisite for getting something merged in, merely sufficient test coverage, a

Re: Django Integration

ething Python recently started doing for similar not-experimental but not-100%-final APIs) (Also, I would posit that the fact it barely changes anything in Django is part of the good design, but I am biased there!) Andrew -- You received this message because you are subscribed to the Google Gr

Call for Channels work

pond here or email me directly! 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+unsub

Re: Django Integration

help fix release blocking bugs > if Andrew isn't available? Are we playing for any or all bug fixes? If > these requests have to go through the MOSS committee, will that delay > getting things fixed? > > Migrations delayed the 1.7 release for months, and I'd like some vote of &g

Re: Django Integration

> there? > > Jacob mentioned he'd been running it on something, but I don't know what exactly, and I only hear mention, not details, of people trying it in production. Personally, it's only running on my own sites, which are anything but high traffic. I had discussed with s

Re: My Take on Django Channels

a much more difficult prospect and one we can only really tackle when we drop Python 2 support. I do believe, however, that the ASGI model maps well to writing an event-based single-process program with async support; in fact, I should probably go write an asyncio in-memory backend version to make

Re: My Take on Django Channels

separate stack to manage it. Do you have an alternate proposal for how Django should integrate websocket support, or do you believe it's not the job of Django to handle at all and should be left entirely to other software? I'm curious, because I obviously believe Django needs to support W

Re: My Take on Django Channels

On Thu, May 5, 2016 at 2:39 PM, Carl Meyer wrote: > Hi Andrew, > > On 05/05/2016 02:19 PM, Andrew Godwin wrote: > > I will put my hand up and say that this sidestepped the DEP process, and > > that's entirely my fault. It was not my intention; I've been working

Re: My Take on Django Channels

at this point for not realising sooner and trying to find ways to not do it - people only pay real attention to a patch as you're close to merging and emotionally invested in it, and it's a little exasperating. Jacob has graciously stepped in to help write one, and I am going to have a

Re: My Take on Django Channels

asty bugs, and I'm still convinced the core design is sound - we'll take it to a DEP and run it through the actual process before merge to make sure that Django is at least on board with that opinion, I owe you that much at least. Andrew -- You received this message because you are su

Re: Django Integration

On Thu, May 5, 2016 at 9:28 PM, Anssi Kääriäinen wrote: > On Thursday, May 5, 2016, Andrew Godwin wrote: >> >> Do you have a link to the presentation about them removing it? >> > > https://youtu.be/839rskyJaro around 34 minutes and onwards, another > version is h

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

on 2. > I agree, and I would love to see more native async code as we go forward that interoperates with both async webservers and async channel worker classes. There is not yet a standard for "async WSGI", and I suspect ASGI can at least partially fulfill this role with the message f

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

er`` is just whatever > bytes > come in off the wire. This also gets exposed in other features, like > backpressure where ASGI didn't currently have a concept of allowing the > queue > to apply back pressure to the web connection but now Andrew has started to > come > aroun

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

I haven't looked at it carefully yet) you're basically > describing the approach taken by hendrix [1]. I'd be curious, Andrew, if > you considered a thread-based approach as an option and rejected it? It > does seem like, purely on the accessibility front, it is perhaps even

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

On Fri, May 6, 2016 at 2:11 PM, Carl Meyer wrote: > > On 05/06/2016 02:31 PM, Andrew Godwin wrote: > > > > On Fri, May 6, 2016 at 1:19 PM, Carl Meyer > <mailto:c...@oddbird.net>> wrote: > > > > On 05/06/2016 01:56 PM, Donald Stufft wrote: >

Re: Django Integration

ing ownership of the git repos and mentioning it in official documentation; this to me seems like a less severe thing than merging it into core, and also something that there is not a deadline preventing so we can discuss it further if needs be. Andrew -- You received this message because you are

Withdrawing Channels from 1.10

achieve with Channels can be done as an external package for now, and hopefully it will prove the correct decision to take. Andrew -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubsc

Re: Withdrawing Channels from 1.10

On Tue, May 10, 2016 at 10:25 AM, Carl Meyer wrote: > On 05/10/2016 10:39 AM, Andrew Godwin wrote: > > - Being almost purely an addition to Django, even though it technically > > inserts a new layer, makes it more well-suited to live externally than > > many other feature

Process DEP for "official" non-core projects

o split out Django into more packages, as well, it could provide a useful base for that to structure around (though we'd want to beef up security/backwards-compat timelines). It's also probably sensible that whatever we come up with covers localflavor, as well, since that's sort of in t

Re: DEPs (was: Making Django more PaaS-friendly)

l the discussion around it seems invaluable for larger features, and would have been Nice To Have given recent events. Andrew -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscr

Re: Process DEP for "official" non-core projects

t; hearing from people who've already been actively involved in localflavor > maintenance. > Me too - I'm not entirely clear what the state of maintenance and releasing is like for it at the moment. Andrew -- You received this message because you are subscribed to the Google Groups &quo

Re: Process DEP for "official" non-core projects

t is probably the better option rather than letting it linger. I would be inclined to merely mark it as deprecated and not drop it from e.g. the GitHub org, though, as where would we move it *to*? Andrew -- You received this message because you are subscribed to the Google Groups "Dja

Re: Process DEP for "official" non-core projects

Good point. I'll get a proper DEP draft written up for next week and then we can comment on it directly with more substance - it sounds like the idea of having one is popular, though, which is what I mainly wanted to check! Andrew On Thu, May 12, 2016 at 12:52 PM, Marc Tamlyn wrote: &g

Re: AJAX support in auth views

would help root a discussion! Andrew On Sat, May 14, 2016 at 11:04 PM, Luke Hodkinson wrote: > Hi all, > > I've been using a patched version of Django for a while now that includes > AJAX support for the login/logout views in contrib/auth. I've searched the > django-devel

Official Projects DEP

ng the existing localflavor under this too). Pull request is up here: https://github.com/django/deps/pull/23 - comments welcome. Andrew -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe

Re: Official Projects DEP

points or opinions on the plan, now is the time! Andrew On Wed, Jun 8, 2016 at 1:34 PM, Andrew Godwin wrote: > Hi everyone, > > I've started on an "official projects" process DEP as I discussed here a > while back, to formalise the process of adopting non-core packages

Re: Official Projects DEP

g set; do you think we should? I think asking the project to come with a plan for that stuff is helpful, and if it would need Fellow involvement, the proposal should include them as part of the maintenance team maybe? Andrew > > > On Friday, June 10, 2016 at 3:01:23 AM UTC-4, Andrew Go

Re: Call for Channels work

self. > > I'd like us to get going on this earlier than November, but I can't offer much extra time towards it; if you can work on drafting a call that would be great. Why would this write you out of pitching for it, though? Andrew -- You received this message because you are subscrib

Re: Official Projects DEP

I've revised the documentation section for clarity about external hosting, and given the lack of further discussion or dissention, I'm now taking the DEP to the technical board for a decision. Andrew On Sun, Jun 12, 2016 at 4:35 AM, Andrew Godwin wrote: > > On 12 Jun 2016

Re: Official Projects DEP

I am happy to report that the Official Projects DEP, number 0007, was approved by the Technical Board and is now adopted as final! Andrwe On 4 Jul 2016 11:39 am, "Andrew Godwin" wrote: > I've revised the documentation section for clarity about external hosting, > and give

Proposing Channels as an Official Project

t move for Channels; adopting it as an official project and mentioning it in the official docs gets us a long way to filling the hole I first saw in Django without going all the way into core straight away. Andrew -- You received this message because you are subscribed to the Google Groups "Dj

Re: Proposing Channels as an Official Project

time to dedicate, security coverage, burnout and the "bus factor" both mean a single-person project is not the best approach. Andrew On Fri, Jul 15, 2016 at 6:26 PM, Andrew Godwin wrote: > Hi everyone, > > Now the Official Projects DEP has landed, I would like to su

Re: Django Channels and WebSocket Routing and URL Parameters

g = [ # You can use a string import path as the first argument as well. include(chat_routing, path=r"^/chat"), ] You can read more in the docs here: http://channels.readthedocs.io/en/latest/getting-started.html#routing Andrew On Thu, Aug 18, 2016 at 7:45 AM, Robert Rosk

Channels is now an official Django project!

need to be done (there'll be deprecation warning code in there so things don't mysteriously break on upgrade). Andrew -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from

Re: Channels is now an official Django project!

e any questions or clarifications, please say and I'm happy to discuss. --- Andrew On Fri, Sep 9, 2016 at 4:08 PM, Tim Graham wrote: > Could you please share the information that you submitted to the technical > board as per the DEP: "The Shepherd will submit the project, the list of &

Re: Channels is now an official Django project!

hannels and its merits and downsides constantly. I tried to build on the problems people had with my merge approach and do this slowly, define a process, and get people involved - I'm not sure what else I could have done? Waited another two months? Andrew On Fri, Sep 9, 2016 at 4:51 PM, Tim Grah

Re: Channels is now an official Django project!

helps improve the process > for next time. I'm interested to see how this experiment turns out. > Thanks, and I am as well - this is new ground for all of us, I think, and while I'd like it to end up working fantastically, we can also learn along the way and work out how to better

Re: Adding aggregates to ModelAdmin.list_display

We have an implementation of both annotations in *list_display* and adding an aggregates for the entire list (which we call *list_summary* and what you are calling here *list_aggregates*) and there are a bunch of subtleties in the interaction due to Admin's built in support for pagination and f

Re: Django Channels Load Testing Results

You might want to run a small site with WebSockets - there are a number of reasons to use ASGI mode, and it's important we make it scale down as well as up. Andrew On Mon, Sep 26, 2016 at 1:30 PM, Chris Foresman wrote: > Why would you be running a small website in ASGI mode with

LiveServerTestCase change in Django 1.11 means can't run functional tests against external server?

Very much appreciate the Django framework. I noticed in the docs for Django 1.11 that the *DJANGO_LIVE_TEST_SERVER_ADDRESS* environmental variable is slated to be removed, along with the accompanying

Re: Django Channels for Client - Server asynch connection

open GitHub issues against the project. Since I see you have cross-posted this question to both lists (please don't do that), I will answer on django-users. Andrew On Sun, Oct 16, 2016 at 9:37 AM, Amirtpal wrote: > Hi Django folks, > > Just a couple of questions on using Django

Re: A command to optimize a squashed migration?

I would say that a command to re-optimise a single migration would be a good idea, especially since it needs no changes to the stored set of run migrations since it would theoretically do the same thing. Andrew On Mon, Oct 31, 2016 at 1:58 PM, Shai Berger wrote: > Hi, > > I

Re: LiveServerTestCase change in Django 1.11 means can't run functional tests against external server?

t;> $ python -m unittest discover -p 'test_functional_*.py' >>> >>> Unfortunately, you'll lose a lot of power in not being able to reuse >>> your form code, assert anything about the database state on the remote >>> server, access django assertion m

Channels Update, November 2016

s like this (or having another maintainer do it) on roughly a monthly basis going forward, though there'll be less content than this first initial knowledge dump. I'd like to make sure people can keep abreast of Channels work and plans without scouring through the mailing lists and

Re: RFC: DEP 7 - dependency policy

a few checks for what it means to be maintained? It's not something I think we could make hard and fast rules for, but a sort of checklist for us to use to check dependencies every release might be useful. Andrew On Sat, Nov 5, 2016 at 1:23 PM, Jacob Kaplan-Moss wrote: > Hi all - > >

Re: Rethinking migrations

ration runners - you can re-use all the nasty work in the schema editing interface and just replace the other part. This huge change is the sort of thing I'd want to see working and proven before we considered changing core, preferably as a third-party app, but of course I'd like to talk through p

Re: Rethinking migrations

es, constraints etc. involved. I wrote a more advanced introspection backend as part of the migrations work, but you'd need to extend it even more and improve upon features like foreign key implication before it would be possible to do this. Andrew -- You received this message because yo

Re: Django Channel asgi specs - question on how to handle a websocket connection

ebsocket. Specifically, this message would reject a pending socket at the HTTP level: {"accept": False} While this would close it with an error code at the WebSocket level: {"accept": True, "close": 1006} It's not the best, I'll agree, but I feel like it

Marking flushed sessions as not modified

n sessions? Is there a bad side-effect of this I haven't considered? 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,

Re: Marking flushed sessions as not modified

work. Andrew On Mon, Jan 23, 2017 at 11:57 AM, Tim Graham wrote: > I'm not sure offhand. Could you provide a link to the issue so we could > look at the details? > > > On Monday, January 23, 2017 at 1:45:48 PM UTC-5, Andrew Godwin wrote: >> >> An interesting bug ha

Re: Marking flushed sessions as not modified

and see if I can see examples of how people call it. Andrew On Tue, Jan 24, 2017 at 6:50 AM, Tim Graham wrote: > The change you proposed might be acceptable, although I'm a bit nervous > about breaking backwards-compatibility in some unforeseen use case. I > wonder if modifying the

Re: Some thoughts about improving migration squashing

't touch by default (e.g. SQL), but it's probably more work to be less generally useful. Andrew > > On Wednesday, February 15, 2017 at 1:22:11 PM UTC+1, rap...@makeleaps.com > wrote: >> >> Hello everyone, >> >>I spent a couple hours last night trying

Re: Channels: get IP address of client websocket

It's in the connect message, as message['client']: http://channels.readthedocs.io/en/latest/asgi.html#connection Andrew On Fri, Feb 17, 2017 at 10:05 AM, Fabien Millerand wrote: > As far as I know I cannot get client websocket public IP address with > channels. >

Re: maximum number of connection using django-channels

g 10 messages a second, you'd only need one Daphne instances but lots of workers. The number of connections Daphne can take depends on a combination of CPU speed and kernel limits; it's not going to be RAM-limited except on very low memory systems. Hope that helps. Andrew On Wed, Mar 1

Re: Will asgi become a PEP like wsgi is ?

, but anyone else on this list who has an opinion should definitely say something. Andrew On Sun, Mar 12, 2017 at 5:44 AM, Sebastian Haase wrote: > (sorry for cross-posting - post should like be here rather than in > django-users) > Hi, > > wsgi is specified by > PEP 333 -- Py

Re: Gevent based ASGI server

main asgi_redis transport? It would improve performance on asyncio or twisted as well. Andrew On Sun, Mar 12, 2017 at 9:54 PM, Jon Pry wrote: > I modified Daphne and the ASGI layer to get the one of the examples to run > under gevent. > > Code is here: > > https://githu

Re: Will asgi become a PEP like wsgi is ?

ugh? Does async support fit in alright? etc. The message formats themselves would work on anything that looks remotely similar. Andrew On Mon, Mar 13, 2017 at 5:17 AM, James Bennett wrote: > WSGI is a framework-independent protocol to allow HTTP servers to > communicate with Python appli

Re: How Channels and Daphne handle huge HTTP requests?

Hi Alexander, I believe Daphne does not yet implement body_channel support for large HTTP requests, just the response version right now. It's on the roadmap, I just need to get round to adding it in. Until then, I would advise not using it for large uploads. Andrew On Sun, Mar 19, 2017 at

Inconsistent Behavior in Auth with UserAttributeSimilarityValidator

the two fields. Is there a reason *not* to make this change? Are there specific reasons for why we are only checking the `username` field during creation? Feedback appreciated. If others approve of this, I will open a PR. Andrew http://jambonsw.com http://django-unleashed.com -- You received

Re: Deprecate is_superuser, is_staff and is_active

I've always felt that `is_staff` should be changed to a permission such as `can_access_admin` provided by the Admin app itself. However, `is_superuser` is slightly different, in that it's not a permission, but rather a flag that says "this user has EVERY permission". It's also potentially nonsensic

Changing how Channels/ASGI receives messages

ed set of channel names, and we can block way more efficiently on servers like Redis. I want to know if anyone has any feedback on this, especially from the "potential problems" department; if not, I'm going to try and get this out before DjangoCon Europe. Thanks! Andrew -- You rece

Re: Changing how Channels/ASGI receives messages

t as well? I think this makes more sense anyway, and that's how asgi_redis will have ended up after my change. 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 a

Re: Changing how Channels/ASGI receives messages

I have added that in to the spec: http://channels.readthedocs.io/en/latest/asgi.html#capacity Andrew On Tue, Mar 28, 2017 at 9:54 AM, Artem Malyshev wrote: > Yes, I saw your changes after I wrote my previous email. > > Global capacity for process sounds reasonable. Probably we should

Re: Changing how Channels/ASGI receives messages

o with a message, that can not be > dispatched to a client socket? This should not happen so often. > Well, given that the reply channel name is generated by the server itself, it should not be possible that the server does not know about it when the client sends it, as the client had to get i

Re: Need to set socket options, for no breaking after a timeout

implements the WebSocket PING protocol to keep data flowing down the socket at regular intervals. Andrew On Fri, May 12, 2017 at 10:52 AM, Victor Porton wrote: > About https://github.com/django/channels > > In the past I dealt with another Python WebSocket engine (unrelated to > Django). Th

Re: Serving static files with Channels

Have you tried removing the staticfiles app from INSTALLED_APPS? I believe that will disable it even with runworker. Andrew On Fri, May 12, 2017 at 11:14 AM, Alexander Prokhorov wrote: > Dear Colleagues, in particular Andrew ;) > > I have a problem with making Channels serve static f

Re: Serving static files with Channels

Then I'm afraid you're stuck for now - you are welcome to open an issue against the Channels project to fix it and even write a patch if you want, but as DEBUG isn't turned on for production installs, it'll be considered a little lower priority. Andrew On Fri, May 12, 2017 a

Re: Channels delay server in development enviromnent

e case. If you switch to the IPC layer (or the Redis layer), you can still use "runserver" and then just launch an extra delay server, and all the components will talk to each other. Andrew On Wed, May 24, 2017 at 5:27 AM, Václav Řehák wrote: > Hi, > > one of the things I li

Re: migration lock file implementation

I am personally unsure about this - it's extra overhead for smaller Django sites, and something that larger teams could easily adopt themselves. I think it might make more sense as a third-party app that plugs in? Andrew On Wed, May 24, 2017 at 12:39 PM, wrote: > To elaborate on this

Re: On ASGI...

gle async handling function, which seems less than ideal to me, or start down the path of having these things represented as classes with callables on them - so you'd call "consumer.connect()", "consumer.receive()" etc., which is probably my preferred design for keeping the e

Re: On ASGI...

of WSGI, and it would not be hard to re-layer Channels to exist behind this pattern. I think at that point the main difference to WSGI is the need to persist state somewhere outside the locals() of the function (as you'll still have separate coroutines for connect/receive/disconnect). Andrew

Re: On ASGI...

nd the restriction about not allowing blocking-listening within a consumer makes deadlock way, way harder. Any interface like this would literally just be "this function gets called with every event, but you can't listen for events on your own"; HTTP request bodies being not an e

Re: On ASGI...

roblem means you simply cannot design around having things all work in a single coroutine unless you go all the way and guarantee that things are _always_ in the same thread so you don't need to do sticky routing. Andrew -- You received this message because you are subscribed to the Google Groups &

Re: Default to BigAutoField

ations and ALTER TABLES this would result in on a large project. We could include in the upgrade notes how to stave it off (explicitly specify an ID field), but I'm sort of on the fence as to if that's good enough. Andrew On Sat, Jun 10, 2017 at 9:53 AM, Collin Anderson wrote: > I mig

Re: On ASGI...

Presumably the equivalent would be true of eg. twisted. > > (There's a couple of diff things you can do to bridge from the asyncio > interface -> sync interface if that's useful) > Yup, you can't make cross-compatible ones. This is why ASGI right now has a receive() me

Re: Consider making asgi_rabbitmq an official Django project.

on to help you maintain it before we could accept it (they would not have to be existing core, but would need some history of open-source maintenance) The other thing would be to see the existing code have more comments and documentation; currently it has very few comments, in particular. Andrew O

Re: On ASGI...

of what I understand. > There are also now initial implementations for both WSGI-to-ASGI and > ASGI-to-WSGI adapters. > > There's a mostly-complete one in asgiref over here for WSGI-to-ASGI: https://github.com/django/asgiref/blob/master/asgiref/wsgi.py If you are feeling l

Re: Consider making asgi_rabbitmq an official Django project.

go project some days). Andrew On Mon, Jun 12, 2017 at 6:19 AM, Artem Malyshev wrote: > Hi Andrew, > > I'm very glad to hear it's considered useful. If you look at recent master > you can see that I've added documentation and comments to the code. > > Exact commit

Re: Consider making asgi_rabbitmq an official Django project.

e of those things). There is an argument to be made for un-parenting the daphne, asgiref, asgi_redis and asgi_ipc projects from Django and just leaving Channels, but that would result in an even worse situation (IMO) of having third-party dependencies that have even less visibility. Andrew On T

Re: On ASGI...

;s easy to write but also lets you scale later. Andrew On Wed, Jun 14, 2017 at 9:53 PM, Tom Christie wrote: > > I note that your examples do not include "receiving messages from a > WebSocket and sending replies" - I would love to see how you propose to > tackle this giv

Re: On ASGI...

ject, as in "channel_layer.async.send()". I'm not sure how I feel about that - thoughts? Andrew On Fri, Jun 16, 2017 at 5:49 PM, Tom Christie wrote: > > I wonder if there is a way of doing something like this well, so that > it's easy to write but also lets you scale la

<    1   2   3   4   5   6   7   >