Re: Automatic prefetching in querysets

Just some quick thoughts, as most of the points I would bring up have been discussed: - This should definitely be opt-in for the first release, it's too big a change to make opt-out straight away. - You should be able to turn it on/off per model, probably in Meta, not in a setting, and obviously

Re: Sending messages to the group does not work after a few minutes online

It seems you send "close": True to the group when a connection comes in, which means that only one websocket at a time is going to be open in it (all others in the group will be disconnected when a new one connects) Andrew On Sun, Aug 6, 2017 at 9:48 AM, Luís Antonio De Marchi

Re: Rethinking ASGI & Channels

On Fri, Jul 21, 2017 at 4:10 AM, Tom Christie wrote: > Hi Andrew, > > Thanks for writing that up so comprehensively! > > Definitely in favor of moving to a server:consumer interface - as you say > that doesn't preclude over-the-network from being one of the possible >

Re: Rethinking ASGI & Channels

stantly. > > Probably this design shift will feet 2.0 release. > > I'll try to implement it in the separate channels branch after PyCon > Russia 2017. > > > On Wednesday, July 12, 2017 at 2:25:27 PM UTC+3, Andrew Godwin wrote: >> >> Hi all, >> >> After

Rethinking ASGI & Channels

Hi all, After recent threads on ASGI and similar problems ( https://groups.google.com/forum/#!topic/django-developers/_314PGl3Ao0), and my own introspection about where we are almost two years in, there are some changes I would like to make to the overall way ASGI/Channels works, both to make

Re: About migrations

There is already a run-before constraint you can add to migrations for exactly this purpose! It's called "run_before" and is in the same format as the dependencies IIRC. Andrew On Fri, Jul 7, 2017 at 6:36 PM, Carl Meyer wrote: > On 07/07/2017 05:09 AM, Patryk Zawadzki wrote:

Re: Websocket, django-channels - an existing connection was forcibly closed by the remote host

Please don't cross-post questions to both mailing lists. I will answer this on django-users after the weekend. Andrew On Sun, Jun 25, 2017 at 9:35 AM, Mike Johnson Jr wrote: > So I'm getting the error as described in the title of this post. > > I'm following this

Re: About migrations

> > > > The advantages comes from db type independency, this is true, but in the > other side you're including the app layer dependency. > > Let's imagine that one of builtin field will change it's definition. > Running migrations on two different Django versions will produce two > different

Re: About migrations

Hi Marcin, Some of these are problems, yes, but you have to understand they are tradeoffs and the alternative is, in my opinion, worse. > I believe that there exist some solution, which drops app layer dependency ands allow using custom fields I would love to see what this would be. I spent a

Re: On ASGI...

> > > > If we end up with one format for channel names and messages that is > spread across two consumption forms (in-process async and cross-process > channel layers), I think that would still be a useful enough standard and > make a lot more people happy. > > Yes. I'm not sure if there aren't

Re: On ASGI...

Right - as long as you make clients deal with reconnection (which obviously they should), then as long as your load-balancing has a way to shed connections from a sticky server by closing them then all should be fine. Honestly, I have always been annoyed at the no-local-context thing in channels;

Re: On ASGI...

Ah, I see, you are assuming sticky sockets. That makes things a lot easier to architecture, but a whole lot harder to load-balance (you have to get your load-balancer to deliberately close sockets when a server is overloaded as many will not go away by themselves). Still, it makes scaling down a

Re: Consider making asgi_rabbitmq an official Django project.

d be nice if channels has its own > technical team rather than giving the impression that the Django > maintainers are also stewarding all other official projects. > > [0] https://www.djangoproject.com/foundation/teams/ > > On Tuesday, June 13, 2017 at 9:22:30 PM UTC-4, Andrew Godwin

Re: Consider making asgi_rabbitmq an official Django project.

ommit https://github.com/proofit404/asgi_rabbitmq/commit/ > 9add0b8fec10ff93f8a813838f4f8ad87fde7e1f > > Also, I found the second maintainer for the project, Andrii Soldatenko. > He is in the mail carbon copy. > > Any insights what to do next? > > Regards, Artem. > > On Su

Re: On ASGI...

On Mon, Jun 12, 2017 at 10:53 PM, Tom Christie wrote: > > def handler(channel_layer, channel_name, message): > > Oh great! That's not a million miles away from what I'm working towards on > my side. > Are you planning to eventually introduce something like that as part of

Re: Consider making asgi_rabbitmq an official Django project.

Hi Artem, I know we've discussed this privately but I want to put some things on the public list (and get at least one reply). My view is that it would be useful to have it maintained, but I do not personally have the spare time to help maintain it, so it would need at least one other person to

Re: On ASGI...

On Fri, Jun 9, 2017 at 8:22 PM, Tom Christie wrote: > Figure I may as well show the sort of thing I'm thinking wrt. a more > constrained consumer callable interface... > > * A callable, taking two arguments, 'message' & 'channels' > * Message being JSON-serializable

Re: Default to BigAutoField

As long as you changed the actual field that ended up under the "id" column, then yes, migrations should detect it and apply all the changes during an upgrade, including to foreign keys. Generic foreign keys are another problem, however, not to mention the prospect of how many migrations and

Re: On ASGI...

On Thu, Jun 8, 2017 at 8:55 PM, Tom Christie wrote: > > 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" > > Gotcha, yes. Although that wouldn't be the case with asyncio frameworks,

Re: On ASGI...

On Wed, Jun 7, 2017 at 7:05 PM, Tom Christie wrote: > Making some more progress - https://github.com/tomchristie/uvicorn > I'll look into adding streaming HTTP request bodies next, and then into > adding a websocket protocol. > > I see that the consumer interface is part

Re: On ASGI...

Right. I'll try and get a full async example up in channels-examples soon to show off how this might work; I did introduce a Worker class into the asgiref package last week as well, and the two things that you need to override on that are "the list of channels to listen to" and "handle this

Re: On ASGI...

Thanks for the continued speedy research, Tom! Weighing in on the design of an ASGI-direct protocol, the main issue I've had at this point is not HTTP (as there's a single request message and the body stuff could be massaged in somehow), but WebSocket, where you have separate "connect", "receive"

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

Re: Channels delay server in development enviromnent

Hi Vaclav, This is because there's only so much we can pack into runserver; when you develop with Celery, for example, you would probably need to run Celery unless you turn ALWAYS_EAGER on (and then not actually see any potential race conditions). If you don't want to run Redis locally, you can

Re: Serving static files with Channels

taticfiles > declares some keywords for templates those apps use. > > > > пятница, 12 мая 2017 г., 22:06:17 UTC+3 пользователь Andrew Godwin написал: >> >> Have you tried removing the staticfiles app from INSTALLED_APPS? I >> believe that will disable it even with runwo

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

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

Hi Victor, Socket handling for the TCP sockets is done by Twisted inside its TCP core, so you would have to look there to see what sort of options they set when opening a HTTP/WS connection handler. I personally have not seen too many issues with WebSocket timeouts, presumably as Daphne

Re: Changing how Channels/ASGI receives messages

On Tue, Mar 28, 2017 at 10:39 AM, Oskar Hahn wrote: > Hi, > > I am not sure, if I understand your proposal correctly. Do you mean, the > asgi server has to listen only to one channel or do you mean it has to > listen to one channel of any channel-type? > > So with redis, do I

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.

Re: Changing how Channels/ASGI receives messages

On Tue, Mar 28, 2017 at 6:27 AM, Artem Malyshev wrote: > Hi everyone, > > It can be huge improvement for asgi_rabbitmq layer. But I'm asking > you to keep this change in the experimental branch before I implement > it for RabbitMQ layer. More questions can came up in

Changing how Channels/ASGI receives messages

Hi all, I wanted to ask your feedback on a proposed change I want to make to the ASGI spec for channel layers. In particular, my goal is to make it so that Daphne only has to receive() on a single channel at any time, massively simplifying the work it takes to poll for new messages and the

Re: Will asgi become a PEP like wsgi is ?

Right, what James says here is pretty much my thoughts; it has been designed from the ground up not to be tied to Django, up to and including the fact that it's in separate packages; all the Django-specific stuff is in the "channels" package, while daphne, asgi_redis, asgiref etc. are useable by

Re: Gevent based ASGI server

Hi John, You are talking about a lot of ideas I want to bring into the main redis transport (improved polling, connection handling, using the channel name local part for routing, etc.), which are separate from using gevent, really; would you be open for contributing this kind of stuff back to the

Re: Will asgi become a PEP like wsgi is ?

Hi Sebastian, The proposal is certainly written like a PEP, and that is somewhat on purpose, but the scope and need for it are still a bit up in the air. In particular, ASGI currently specifies two parts: - An interface for talking to channel-based message queues and a set of guarantees and

Re: maximum number of connection using django-channels

Hi, There's more about how Channels works in the docs and in talks I've given, but the short version is: * Websockets go into a server called Daphne, which is written in Twisted and so can handle hundreds or potentially thousands of simultaneous connections open at once * Any event on a

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. > > I even

Re: Some thoughts about improving migration squashing

> > > You're essentially speaking about 2 things here, in my opinion: > > 1. Adding a new feature for interactive squash > 2. Improving the MigrationOptimizer > > I certainly see a point for 2. Not sure how much for 1. Anyway, your > reasoning for 2 sounds great! I'd be more than happy if you want

Re: Marking flushed sessions as not modified

g the condition in the > channel_session decorator to: if session.modified and not > session.is_empty(): would solve the issue? This seems similar to what the > SessionMiddleware does. > > On Monday, January 23, 2017 at 2:59:59 PM UTC-5, Andrew Godwin wrote: >> >> Here

Re: Marking flushed sessions as not modified

. Andrew On Mon, Jan 23, 2017 at 11:57 AM, Tim Graham <timogra...@gmail.com> 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: >> >>

Marking flushed sessions as not modified

An interesting bug has turned up in Channels where someone is trying to remove a session using .flush(), but our decorator sees that it's been modified and then re-saves it, thinking it needs to persist data. What are people's opinions on changing flush() to also set modified=False on sessions?

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

On Mon, Jan 2, 2017 at 1:10 PM, Oskar Hahn wrote: > Hi, > > this is a question on how to interpret the asgi specs of django channels: > > https://channels.readthedocs.io/en/latest/asgi.html > > If this is the wrong place to discuss it, then please point me to the > right place. >

Re: Rethinking migrations

On Tue, Nov 8, 2016 at 12:34 PM, Patryk Zawadzki wrote: > I've just hit another problem related to custom fields. > > Currently migrations contain information about "rich" fields. If you use a > custom field type, the migration code will currently import your field type >

Re: Rethinking migrations

Hello! I have opinions about this :) > Possible solution (or "how I'd build it today if there was no existing > code in Django core"): > > a. Make migrations part of the project and not individual apps. This takes > care of problem 3 above. > It also means it's impossible for apps to ship

Re: RFC: DEP 7 - dependency policy

I think the "maturity" criteria are pretty sensible, though I am slightly concerned about the potential for a project to be effectively unmaintained even though there's someone's name on it who are active elsewhere. Do you think there's a sensible way we could outline a few checks for what it

Channels Update, November 2016

Hi everyone, It's been almost a year since the Channels funding project started, and a little while since it became an official Django project, and it's been hard to know what the state of it is at times. I'm going to start doing monthly updates on how Channels is progressing and what's going

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

Re: Django Channels for Client - Server asynch connection

Hi Armitpal, django-developers is for discussions about development on Django, Channels and other Django projects themselves, not the use of them. For general discussion we have an IRC channel at #django-channels on Freenode or django-us...@googlegroups.com; for specific requests or bugs you can

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

Re: Channels is now an official Django project!

go grow in the next new direction too. Andrew > On Friday, September 9, 2016 at 11:58:41 AM UTC-4, Andrew Godwin wrote: >> >> I agree some discussion would be nice, but I tried several times to start >> some and was met with silence each time. Given the generally positive >&g

Re: Channels is now an official Django project!

d have been nice to see > some enthusiasm from others about the merits of adopting it as an official > project. > > [0] https://groups.google.com/d/topic/django-developers/ > 24DGLVVRV_s/discussion > > On Friday, September 9, 2016 at 11:14:25 AM UTC-4, Andrew Godwin wrote: >

Re: Channels is now an official Django project!

make > sense to do that in the future? > > > On Friday, September 9, 2016 at 10:58:24 AM UTC-4, Andrew Godwin wrote: >> >> Hi everyone, >> >> The Technical Board approved Channels as an official Django project as >> per DEP 7, and so the repositories have been move

Channels is now an official Django project!

Hi everyone, The Technical Board approved Channels as an official Django project as per DEP 7, and so the repositories have been moved under the django/ project on GitHub, as well as a few other things the DEP requires, and improving the contribution guidelines and triaging tickets. You can read

Re: Proposing Channels as an Official Project

of 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 <and...@aeracode.org> wrote: > Hi everyone, > > Now the Official Projects DEP has lande

Proposing Channels as an Official Project

Hi everyone, Now the Official Projects DEP has landed, I would like to submit Channels for consideration as one. As per the DEP ( https://github.com/django/deps/blob/master/final/0007-official-projects.rst), the final decision is down to the Technical Board, but a discussion phase is an

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" <andrewgod...@gmail.com> wrote: > I've revised the documentation section for clarity abo

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 <andrewgod...@gmail.com> wrote: > &g

Re: Call for Channels work

On Tue, Jun 14, 2016 at 3:03 PM, Tom Christie wrote: > > we don't have a mechanism to delegate the "what should we build" part of > the question for work other than channels. > > I guess there's two aspects to that. > > 1. Do Mozilla allow some flex in meeting the

Re: Official Projects DEP

k 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 Godwin wrote: >

Re: Official Projects DEP

or opinions on the plan, now is the time! Andrew On Wed, Jun 8, 2016 at 1:34 PM, Andrew Godwin <and...@aeracode.org> wrote: > Hi everyone, > > I've started on an "official projects" process DEP as I discussed here a > while back, to formalise the process o

Official Projects DEP

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 as repositories under the official Django organisation, with a view to taking Channels on this route (and hopefully including the existing

Re: AJAX support in auth views

Hi Luke, Could you clarify what you mean by "AJAX support in auth views"? Do you mean the ability to submit requests to these endpoints and get JSON responses back rather than HTML, so the process can be done more client-side, or something else? If you could link the patch too that would help

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

y 2016 at 20:34, William Hakizimana <willyh...@gmail.com> wrote: > >> Just wanted to thank you so much for your hard work. The documentation is >> really well written! >> >> On Wednesday, May 11, 2016, at 1:29:34 PM UTC-5, Andrew Godwin wrote: >>> &

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

On Wed, May 11, 2016 at 11:00 AM, Jacob Kaplan-Moss wrote: > I like this, and +1 on your rough outline. > > There is one missing thing here though: I think we need to consider the > process/policy for removing things if they're no longer maintained. Without > clear

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

On Wed, May 11, 2016 at 10:06 AM, Carl Meyer wrote: > > I'm not quite sure what this means. By "major release" here, you mean > "major release of the adopted project," not "major release of Django"? > So this means that security fixes for the adopted project will be > provided

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

On Tue, May 10, 2016 at 1:58 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > On 10 May 2016, at 19:18, Carl Meyer wrote: > > > I would say that a DEP is generally a good idea if the people working on > > the feature feel that it would be helpful to them to

Process DEP for "official" non-core projects

Hi everyone, Following my decision to move Channels away from a 1.10 merge and towards an existence as a separate app for a bit while it matures, I would like to write up a process DEP for how we achieve this - specifically, what it takes to be adopted as a non-core app, what that means for the

Re: Withdrawing Channels from 1.10

On Tue, May 10, 2016 at 10:25 AM, Carl Meyer <c...@oddbird.net> 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 &g

Withdrawing Channels from 1.10

Hi everyone, I'm going to withdraw the Channels patch for consideration for 1.10; there's a lot more concern and uncertainty around it than I had anticipated, given the reaction up until this point, and it's clear I have some more work to do at convincing the community and proving the design.

Re: Django Integration

On Mon, May 9, 2016 at 6:42 PM, Tim Graham wrote: > I'm not convinced either way about whether putting this in core will help > mature it and fix bugs more quickly or not. I don't have any sense of how > the code might change after we merge it, but things get more

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 <c...@oddbird.net> wrote: > > On 05/06/2016 02:31 PM, Andrew Godwin wrote: > > > > On Fri, May 6, 2016 at 1:19 PM, Carl Meyer <c...@oddbird.net > > <mailto:c...@oddbird.net>> wrote: > > > > On 05

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

On Fri, May 6, 2016 at 1:19 PM, Carl Meyer wrote: > On 05/06/2016 01:56 PM, Donald Stufft wrote: > > User level code would not be handling WebSockets asynchronously, that > > would be left up to the web server (which would call the user level code > > using deferToThread each

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

Want to just cover a few more things I didn't in my reply to Aymeric. On Fri, May 6, 2016 at 9:11 AM, Donald Stufft wrote: > > > In short, I think that the message bus adds an additional layer of > complexity > that makes everything a bit more complex and complicated for very

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

On Fri, May 6, 2016 at 10:09 AM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Hello Donald, all, > > Some thoughts inline below. > > > On 06 May 2016, at 18:11, Donald Stufft wrote: > > > > For an example, in traditional HTTP servers where you have an open >

Re: Django Integration

On Thu, May 5, 2016 at 9:28 PM, Anssi Kääriäinen <akaar...@gmail.com> wrote: > On Thursday, May 5, 2016, Andrew Godwin <and...@aeracode.org> wrote: >> >> Do you have a link to the presentation about them removing it? >> > > https://youtu.be/839rskyJaro

Re: My Take on Django Channels

On Thu, May 5, 2016 at 5:13 PM, Mark Lavin wrote: > Yes I agree with the value of a standardized way of communicating between > these processes and I listed that as a highlight of Channels, though it > quickly shifted into criticism. I think that's where we are crossing

Re: My Take on Django Channels

On Thu, May 5, 2016 at 4:22 PM, Carl Meyer wrote: > > I've no desire either to aggravate your RSI or kick you in the teeth! I > understand the multiple competing pressures here and won't stand in the > way of a merge into 1.10 sans DEP if that still seems like the best path >

Re: My Take on Django Channels

On Thu, May 5, 2016 at 2:39 PM, Carl Meyer <c...@oddbird.net> 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 i

Re: My Take on Django Channels

On Thu, May 5, 2016 at 2:19 PM, Mark Lavin wrote: > Thank you for your comments and I have some brief replies. > > > If I'm understanding it correctly, groups are an emulated broadcast. I'm > saying it would be an advantage for it to use pub/sub but it does not. > You are

Re: Django Integration

On Thu, May 5, 2016 at 12:55 AM, Anssi Kääriäinen wrote: > On Thursday, May 5, 2016, Russell Keith-Magee > wrote: > >> I will admin that I haven’t been paying *close* attention to Andrew’s >> work - I’m aware of the broad strokes, and I’ve skimmed

Re: Django Integration

On Wed, May 4, 2016 at 6:12 PM, Tim Graham wrote: > The future is hard to predict, but I'll add that I'm a tad nervous about > this as well. > > I'm completely inexperienced with channels at this time. Who else has a > good grasp of the code right now and could help fix

Call for Channels work

Hi everyone, We finally have everything in place to pay people from the MOSS funds given to us by Mozilla for Channels (and more importantly we now have the money itself), so now I'd like to open the call for help. We have a list of tasks that need doing in Channels, and the money to pay people

Re: Django Integration

On Wed, May 4, 2016 at 12:28 PM, Mark Lavin wrote: > I can (and do) appreciate the effort that's gone into this work while > still feeling as though it isn't ready to be merged with Django. To be > honest given that this PR contains almost no changes to Django itself and >

Re: Django Integration

On Wed, May 4, 2016 at 11:52 AM, Mark Lavin wrote: > > > Given that there is no guarantee of message delivery, I don't think this > is suitable or recommended for using for background tasks. I don't think > the Django docs should encourage that usage. At least without a

Re: Django Integration

On Wed, May 4, 2016 at 10:06 AM, Markus Holtermann wrote: > What about having asgiref and daphne as optional dependencies instead of > hard once and raising a proper exception "please install ..." when the > import fails? > > ``` > try: >from asgiref import ... >

Re: Django Integration

em 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). Considering we're launching Channels in 1.10 as a "provisional" feature, my opinion would be that we can go

Re: Django Integration

On Wed, May 4, 2016 at 6:15 AM, Mark Lavin wrote: > I had assumed this was still a work in progress because there are missing > tests and some documentation. The build is passing but the unittest > coverage for the new modules seems low or at least not up to the standards >

Re: Django Integration

]? Do you think you might have it > ready by next Monday or so, so that I'll have at least a few days to review > it before the alpha scheduled for May 16? > > [0] https://github.com/django/django/pull/6419 > > On Saturday, March 5, 2016 at 7:49:41 PM UTC-5, Andrew Godwin wrote: &

Re: Feedback on Django Channels

> > > Well, in that case I would consider defining the consumer as a required, > but > keyword (and keyword-only in Python3) argument, specified in the end by > convention. Putting it between the channel and channel parameters is ugly > IMO. > > It would be easy enough to change all the docs and

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

Re: Feedback on Django Channels

On Tue, Mar 22, 2016 at 4:04 PM, Michael Manfre wrote: > > If not provided out of the box, there needs to be a supported way of > wiring in encryption. The security/compliance person at my job stated that > only securing the transport was not good enough for our compliance >

Re: Feedback on Django Channels

in-transit is a > basic requirement of nearly every regulatory regime, and we should do what > we can to help. > > [2] https://cryptography.io/en/latest/fernet/ > > On Mon, Mar 21, 2016 at 7:15 PM, Andrew Godwin <andrewgod...@gmail.com> > wrote: > >> The channel l

Re: Feedback on Django Channels

then use the SECRET_KEY to decrypt the > message. It'd be nice if encryption were an option encoded within the > message or route somehow, so it could be optionally turned on for sensitive > data. I'm guessing that there's probably an issue with my assumptions > though. > > On Tuesda

Re: Feedback on Django Channels

On Mon, Mar 21, 2016 at 12:11 PM, Sean Brant wrote: > How does the new channels model handle requests with sensitive > information? Say you have a login view and the user is submitting a > username/password. Does the password get serialized into the message queue > as plain

Re: Feedback on Django Channels

On Mon, Mar 21, 2016 at 9:55 AM, David Evans wrote: > On the static files question, I'm about to release v3 of WhiteNoise ( > http://whitenoise.evans.io/en/latest/changelog.html) which provides the > option to integrate via Django middlware, rather than wsgi middleware. (It

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 <r...@ryanhiebert.com> wrote: > > On Mar 18, 2016, at 9:58 AM, Andrew Godwin <and...@aera

Re: Feedback on Django Channels

w, > > Ah, excellent. I just took a short break (too many LOC at work today), and > while I was away I was thinking about all of this. > > Here's what I came up with: > > https://gist.github.com/orokusaki/17b4cf734b4d2f2af117 > > On Friday, March 18, 2016 at 3

Re: Feedback on Django Channels

)$'), > > # Catches any UK phone number and routes to UkSmsConsumer > route('sms.receive', sender=r'\+44(?P[0-9]+)$', > UkSmsConsumer), > ] > > Is that right? > > On Friday, March 18, 2016 at 5:18:51 PM UTC-4, Andrew Godwin wrote: >> >> I like most of it

Re: Feedback on Django Channels

On Thu, Mar 17, 2016 at 1:41 PM, Jacob Kaplan-Moss 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

Re: Feedback on Django Channels

Hi Vincent, I think you make some good points - in particular, I think includes are probably a necessity, as you say. However, I disagree we should let people have either channel->url or url->channel; I'd like us not to try and give people multiple ways to do things if we can help it, especially

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` ( >

<    1   2   3   4   5   >