I'm uncertain how popular the suggestion will be but ... are "channels" the 
right solution to our async/concurrency problems? ( I'm all for 
django-channels the project and the work to solve these issues)
All the talk of channels, workers, queues and back ends in the explanations 
I'm reading as I follow along with the progress of 'Django Channels", just 
feels "less good" than solving this problem via Actor Model Concurrency 
(championed by Erlang, Elixir, Stackless Python, etc). 

There is an excellent actor model concurrency library for python that 
already supports 'async django'. "Pulsar" 
(http://pythonhosted.org/pulsar/index.html) and the documentation here 
http://pythonhosted.org/pulsar/apps/pulse.html shows two different ways to 
use actor model concurrency to attack the issue of using Django with 
asynchronous web stuff like Websockets, etc.
Some of what's being described in the explanations of Django channels 
sounds very similar to what they provide to work around the limitations of 
django's blocking request processing cycle other parts sound much more 
complicated, for instance the need for various back ends 
in-memory/redis/etc.

I know Pulsar is currently Python 3.4 and newer only, but in the past it 
supported 2.7, so anything we can learn from their concurrency approach can 
work on Python 2.7 to maintain our backwards compatibility going forward. 
You can see an example of Pulsar using python 2 if you look on the 
benchmark page for their python powered 'redis clone' 
- https://gist.github.com/lsbardel/8068579 - One of the benchmarks is using 
pypy so the code definitely worked in a python 2.7 environment.

Would the work to integrate channels as part of Django improve the ability 
to run Django in a completely async mode and enhance its performance when 
run under Pulsar? or would it just be something that needed to be turned 
off if we wanted to use something like Pulsar to power our "async django". 
Is there anything to be gained from using a more actor driven concurrency 
model or adopting any of the other methods used in their 'pulse' django app?
I suppose I'm just trying to work out how to compare using Django-Channels 
with using Pulse from the Pulsar project.

On Wednesday, 16 December 2015 19:23:56 UTC+8, Andrew Godwin wrote:

>
> On Wed, Dec 16, 2015 at 9:52 AM, Markus Holtermann <
> [email protected] <javascript:>> wrote:
>
>>
>> >If I get it right -- Curtis' description is spot-on; some tasks will
>> >still
>> >need Celery, Channels will take care of many others.
>>
>> For me it's more a question of "is a client directly involved".
>>
>
> I don't agree; I think it's more "do you have enough workers to handle 
> this". Channels makes all workers serve all requests, so if you're doing 
> e.g. video encoding you can't segregate it from request handling. However, 
> you could have multiple channel backends and thus multiple worker pools to 
> achieve 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 [email protected].
To post to this group, send email to [email protected].
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/1d6526d3-dd55-4719-b1ba-4804d4eb2dff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to