--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/CAFwN1uonedcUeLz8zD%2BK5Ma82gLyAX8g0s58HeT%3Dq-dMgcLxfw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAB5Hk3yC0MnbJwh%2BMQ63%2BdXha9pnBo6zL_kp2n5wNd8oqkT1UQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAB5Hk3yC0MnbJwh%2BMQ63%2BdXha9pnBo6zL_kp2n5wNd8oqkT1UQ%40mail.gmail.com.
--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/CAFwN1uonedcUeLz8zD%2BK5Ma82gLyAX8g0s58HeT%3Dq-dMgcLxfw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Given that, if nobody else can step forward to take over, I'll have to put those three projects (Channels, channels-redis, and Daphne) into an explicit maintenance mode where they only accept security requests via the normal security@ route, and start the process of retiring them as active Django projects, as I don't want to give the impression they're still maintained if they're not.(note: the asgiref project is still fine and should probably move out of Django to its own effort at some point giving the growing set of ASGI tools)
Once I recover a bit from the burnout I'll be able to come back and help with the really complex bugs; the main thing I need out of is the seemingly endless support requests and weird WebSocket client bugs.
--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/68626427-d97d-4053-8836-5382483f63af%40googlegroups.com.
Hey Andrew.
I've been thinking a lot about this. You clearly shouldn't be maintaining Channels single-handedly indefinitely.
I know Channels started out separately, but, it's time to think about what, if anything of channels, is to be brought into core, or become THE WAY we do things or... Yes, we need more hands, but there's a bunch of people who can help out, and at least part of the problem is your out there in the wings by yourself (with not much visibility.)Q: How does Channels fit into the "Django Async Roadmap"?To the extent that it does, I think there's a case for asking the board and the DSF more widely to throw everything we've got behind making sure it's properly resourced.
I presume you DON'T offer support on the issue tracker, and point people to other channels? I'd be happy to "straight-bat" obvious tickets away. (Michael's offer to recieve is valuable there.)
"...and weird WebSocket client bugs."Can I ask you to explain what you mean there? (Point to a ticket maybe.) What kind of query do you get? Is there a particular knack to working out if it's a valid bug or not? (Or is it apparent?)
Thanks for all you work here. Legend. 🙂
I feel, is that is solves the wrong problem - it's focused on WebSockets, which is a niche feature that a few people are happy we provide but most people have no practical use for.
"I need a general purpose async platform and it would be great if it worked with Websockets, ZeromQ and played nice with Django..." (therefore Django Channels vs Tornado vs ...)
"I need to build real time features with Websockets using Django.." (therefore Django Channels).
To me, Websockets is the defining use case for using Django Channels. From a user POV, saying that Channels is focused on the wrong problem (websockets) is like saying Django is too focused on HTTP.When I have selected Channels (vs other tools), my rationale was not:"I need a general purpose async platform and it would be great if it worked with Websockets, ZeromQ and played nice with Django..." (therefore Django Channels vs Tornado vs ...)rather my rationale is more like:"I need to build real time features with Websockets using Django.." (therefore Django Channels).
Hi,
I'm no experienced developer nor a Django contributor, but I
"suffered" from this theme too. What I tried in the past is to
create a Django "application", or more a framework
(https://pypi.org/project/gdaps/), to support "plugins" which
consist of a backend (the django part), and an included frontend
(which shoud contain a "plugin" of a Js-framework like Vue.js or
Angular, etc) that "blends" in into the web client dynamically.
I have experimented with using templates serving Vue code, or separating the part that is served to the browser from the Django backend in a different directory, bypassing Django templates, and did not succeed much.
This all is not directly related to the theme here, but where it is connected, is that, for writing a modern application nowadays, you IMHO have to be responsive in the frontend, and I think that async calls are not smart enough to solve that.
If you ever tried the "easiness" of Meteor, you always envy that when using Django with templates.
So: If I had a wish to Santa Claus :-), I would really support Django having "Channels" (or however it may be named) included more deeply into the system: I think that the Templates approach is not the worst, because it is very flexible. It just doesn't have a solution to the communication problem between server and client. Again, if I could wish something, It would be Integration of frontend frameworks into the template language and having calls to e.g. DRF included INTO the template language, like the "batteries included" approach of Meteor with their "connected" variables that update automatically when another client changes them.
This all is possible with Django DRF, channels and a modern Js framework, but VERY much boilerplate code and hand-written updates, no-way modern.
I know it's much I demand here - I just want to add my 2cents - Django is GREAT software.
It's just that the frontend side (templates, auto-communication and data bindings) did not gain that much love as the backend.
Maybe you'll say "Hey, Django IS only a backend". Yes and no. If so, you can remove the templates completely. It's not a backend, it just focussed on the backend more than on the frontend.
If there would be a way to integrate channels more deeply into Django, together with frontend 2-way data bindings, push notifications etc., I would really appreciate it and could imagine supporting that using money too.
Cheers,
Christian
--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/b357add7-cd44-4c12-b29b-0d28150417a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
-- Dr. Christian González https://www.nerdocs.at +43 650 7644477