Re: Django Chat Application using channels and SQS

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for the development of Django itself, not for support using Django.
This means the discussions of bugs and features in Django itself, rather
than in your code using it. People on this list are unlikely to answer your
support query with their limited time and energy. Read more on the mailing
lists at https://www.djangoproject.com/community/

For support, please use the django-users mailing list, or IRC #django on
Freenode, or a site like Stack Overflow. There are people out there willing
to help on those channels, but they might not respond if you don't ask your
question well. Stack Overflow's question guide can help you frame it well:
https://stackoverflow.com/help/how-to-ask .

Also if you haven't read it, please take a look at Django's Code of
Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
rules" for working well as a community, and will help you get the most out
of Django and our fantastic community.

Thanks for your understanding,

Adam

On Sat, 17 Aug 2019 at 09:04, Varun Jain  wrote:

> *Problem Statement: *Build a scalable chat infra using django/python, do
> assume that you will have to scale this horizontally.
>
> I am still to get the other specifics about the product expectations but
> here is what I understand matters:
>
> a. Acceptable Latency between messages/events
> b. Number of open connections/user possible per server
> c. Size of messages/payload (more on this in a minute).
>
>
> This is what my solution needs to look like (generic, not specific to
> django/python)
>
> *Client Web Socket Component  (CWSC)*
> A group of servers that can:
>
> a. Accept an incoming user's connection request over web socket protocol
> and initiate a sticky session.
> b. Accept messages/events from a user
> c. Receives messages/events received for the connected user and passes it
> on to the frontend client
> d. Stores the messages in a persistent db (PostgreSQL)
> e. *Broadcasts the message to a  pub/sub style channel *for other servers
> to listen for.
>
>
> *Central Redis User-Server Map*
>
> Since we are assuming a distributed system the two users might not be on
> the same server. In this case we need to know the receiver user's server
> (so that it can added as meta-data to the message broadcasted by CWSC).
> This meta data can be used the receiving server to filter messages meant
> for it as the pub/sub channel broadcasts to all server's subscribed to a
> particular channel.
>
> This db would hold the a mapping of user to server. Whenever a new
> connection request happens (a) above, it would also add an entry to the
> redis db.
>
>
> *Pub/Sub Channel *
>
> This is where messages/events are broadcasted. Assuming simplicity of only
> one type of event it would only have channel, that all servers would have
> subscribed to. Other types of channels could be (message read event,
> picture sending event etc)
>
>
> Here is my understanding of how this can be done using django-channels:
>
> 1. Django channels is the CWSC component here. It provides for a handy
> framework to write the implementations
>
> 2. Pub/Sub channel is the *channel layer *concept within django-channels
> that uses *channel_redis * as the backend.
>
> 3. Central redis user-server map is just something I came up with for my
> design and can be a very simple EC2 server running the same.
>
>
> Here are my questions:
>
> 1. How does using django channels compare to using socket module directly
> in python? In terms of performance/scalability. I am not looking for a
> silver bullet here and understand that it is all a question of product
> specifics but is it reasonable to expect it to scale to half a million
> users without us having to open up the package and make modifications to
> it? My understanding of django-channels is that it is built on socket in
> python but in a django-friendly manner.
>
>
> 2. Is channel_redis using redis pub/sub underneath?
>
>
> 3. Can I use something like Amazon SQS instead of channel_redis? If so any
> relevant resources/packages would be great.
>
>
> 4. Is there something else you would want me to know?
>
>
>
>
>
>
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/35606039-9d10-4ed2-9926-46dd9febf765%40googlegroups.com
> 
> .
>


-- 
Adam

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

Re: Ideas for a new DEP on long-term Django API compatibility

[Aymeric Augustin]

Hello Pascal,

As we're getting to the end of useful arguments here, I'd like to ask you to 
step back for a minute and take a calm look at what you're writing. Imagine you 
were receiving such messages rather than sending them. Would you want to spend 
more time collaborating with the person addressing you that way and to receive 
more such messages? Perhaps this is another reason why you aren't getting as 
much support as you'd hope.

You did your best to provide nuanced feedback on a debatable 
backwards-compatibility issue — current behavior is obviously wrong but can't 
be fixed without a hard compatibility break:
> some wild guess / wishful thinking

You spent thousands of hours thinking about what would be best for users of the 
framework — getting occasional thanks and only occasional abuse, as we're lucky 
to have a positive community:
> what is practical for core developers is NOT the same as what is practical 
> for users

You don't need backwards compatibility because you're comfortable living on the 
edge but you always take the time to create deprecation paths according to the 
compatibility policy:
> even if it means creating a task force just for keeping a slight eye on 
> compatibility shims

You do your best to discuss positively with an agressive contributor who 
started with a strongly-worded blog post and doesn't seem to process the 
responses he's getting:
> All that to face red herrings


Here's literal belittling:
> *your* little version of Django


And the cherry of the cake, stating core devs are secret sadists:
> Punishing users


This isn't how we hold discussions here. You need to take a clue from how other 
people interact on this mailing list. Then you can put your energy and ideas to 
good use for improving Django.

>From a pragmatic perspective, putting people off isn't a good way to get them 
>to cooperate with you.

For example, Luke was open to amending the deprecation policy to better reflect 
reality. You should have suggested some concrete changes, erring on the side of 
caution. Instead you chose to repeat the same argument, except more 
agressively. This doesn't get us any closer to a documentation patch. In fact 
this reduces the likelihood that someone will choose to spend time writing that 
patch.

You last email sounds like you're throwing your toys and walking away because 
you didn't get full agreement with your position. However, that outcome was 
largely predictable when you were bringing up a position that diverges so much 
from the current practice. To create progress, it's up to you to create 
consensus around small steps and to create the corresponding pull requests, in 
that order.

Best regards,

-- 
Aymeric.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/E1632450-C0E8-410F-A3BB-03B5FAD94C13%40polytechnique.org.

Re: Django LTS support time

[James Bennett]

The main issue with an LTS is that there's no such thing as "long enough".
Upgrading once every three years -- especially when the compatibility
policy now is that if you run on the previous LTS with no deprecation
warnings, you'll also be able to run on the next LTS without errors -- is
not that much of a burden. But many organizations won't put in the time to
do the upgrade until it's too late, and the length of the support period
doesn't actually matter: an organization that can't manage an upgrade in 3
years also won't manage an upgrade in 5 years, or even 10 years, because
the problem is not that the support period was too short. The problem is
the organization's priorities, specifically the fact that doing maintenance
work is not a priority.

A good example is Python 3 support. Python 3 was first released 11 years
ago, and Django introduced support 6.5 years ago once Python 3.2/3.3
stabilized a lot of things. But there are still people today who haven't
even *started* to upgrade to Python 3. It wouldn't matter if we gave them a
hundred years -- it still wouldn't be "enough time" for them to upgrade.

I understand the arguments for *why* organizations do this -- which mostly
come down to "it works right now, why should we spend time on something
that isn't broken when we have real bugs to fix and features to add?" --
but unfortunately they usually end up learning, when it's too late, why
they should have made time for maintenance work earlier. Giving them a
longer support period won't change this. And a 3-year support period is a
reasonable amount of time, especially given the work being done to make the
LTS-to-LTS upgrade easy, and doesn't overburden the Django team with having
to support ancient versions of the framework until the end of time.

With that said, there are Linux distributions which provide their own
packaged version of Django, and which have longer support periods in which
they will backport important fixes into their package even if the Django
team isn't supporting that version anymore. Some of them charge money for
this service, but if you need to buy a couple more years of support for an
old version of Django, using one of those distributions may be your best
option.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg8G2fU1XXi6%2Bx%2B55ReYJhmVbGXjZObz50sneZF4Jtk7fA%40mail.gmail.com.

Re: Django LTS support time

[Levi Cameron]

>
> With that said, there are Linux distributions which provide their own 
> packaged version of Django, and which have longer support periods in which 
> they will backport important fixes into their package even if the Django 
> team isn't supporting that version anymore.
>

Specifically:

   - The django package in Ubuntu is in main 
    (ie maintained by 
   a paid Canonical employee for the lifetime of the OS)
   - Django 1.6 was EOL in April April 2015 but Ubuntu 14.04 LTS was 
   maintained until April 2019 (the last changelog 
    was 
   from Jan 2019 -- that's almost 4 years of backports). You can get an extra 
   3 years on top of that if you want to pay Canoncial.
   - Django 1.8 was EOL in April 2018 but Ubuntu 16.04 LTS is maintained 
   until 2021 (and Canonical are still applying backports 
   
).
 
   As above, 3 years extra if you pay.
   - Django 1.11 is EOL life in April 2020 but Ubuntu 18.04 LTS is 
   maintained until 2023, or 2028 (+5 years) if you want to pay.
   - This comes to a full 9 years of updates from first release for django 
   1.6 & 1.8, and 11 years for django 1.11
   

If Ubuntu isn't your thing then RHEL has a 10 year support guarantee (for 
free if you can tolerate the unpredictable lag between RedHat and CentOS 
releases).

If you don't want to be tied to a specific linux distribution then you also 
have ActiveState  (which only depends on 
glibc).


In short, it's certainly not like there aren't already extended options if 
the default django 3 year policy is not enough. If someone really needs 6+ 
years of updates then it seems reasonable to me that they pay someone to do 
that work instead of expecting it from volunteer django maintainers.


Levi

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a562dc2a-566b-427d-a0d8-1a077c66c32f%40googlegroups.com.