On Wed, Dec 16, 2015 at 6:22 AM, Andrew Godwin <[email protected]> wrote: > > > On Wed, Dec 16, 2015 at 9:52 AM, Markus Holtermann > <[email protected]> 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".
as i read it: celery has an specific use pattern: the Django process emits a message to some other process. It doesn't alter the request/response cycle in any way. the most common use is to initiate a 'background process' from the request-bound Django process to another, non-Django process. The "channels" design makes Django a processor of messages, the first example is a 'normal' http request, which would be just a message from the user. another example is asynchronous request/responses, typically WebSockets, SSE, etc. finally, it could also allow a Django process on the receiving end of an intra-server message. A future version of Celery could use that as a new infrastructure option. -- Javier -- 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/CAFkDaoRiRJiOUQK-xCi8kwkrR%3DV9K6rMw%2BstZ16ZOrNn7%3D_0Mg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
