Hi,
This is the third feature proposal as part of my general drive for
getting Django to work better for javascript heavy sites.
Support Server-Sent Events
--
If you want a snappy user experience, AJAX polling isn't enough. There
are two major ways to get out of the r
Hi Collin,
I'll answer in this thread to keep here things tidy.
Since Server-Sent Events are just HTTP you can scale them the same way you
scale your normal web app. Split users so some users hit one server and
some users hit another. Then let Django communicate with all server
processes inste
Hi Emil,
while supporting server-sent events (or even websockets for that matter)
would be great, this is basically a problem which has to be tackled in WSGI
first in my opinion. That said, when you talk about a separate process, how
would it look like (aside from using asycio), ie how would i
Hi,
The separate process would have none of Django's features, it would just be
a way to send messages to connected clients. Here's an example of how it
could work:
- Client A and Client B connects to my site. Django serves the start
page as normal.
- The start page serves up a javasc
On Sat, May 30, 2015 at 4:19 PM, Florian Apolloner
wrote:
> ie how would it use Django's current featureset which is basically blocking
> everywhere…
On Sat, May 30, 2015 at 4:40 PM, Emil Stenström wrote:
> The separate process would have none of Django's features, it would just be
> a way to se
> On Sat, May 30, 2015 at 4:19 PM, Florian Apolloner
> wrote:
>> ie how would it use Django's current featureset which is basically
>> blocking
>> everywhere…
>
> On Sat, May 30, 2015 at 4:40 PM, Emil Stenström wrote:
>> The separate process would have none of Django's features, it would just
>>
On Sun, May 31, 2015 at 1:23 AM, Roberto De Ioris wrote:
> I obviously agree, but take in account that this uWSGI plugin simplified
> the steps a lot:
>
> https://github.com/unbit/uwsgi-sse-offload
nice. it certainly looks cleaner than having an external gevent
process. does it support sending
> On Sun, May 31, 2015 at 1:23 AM, Roberto De Ioris
> wrote:
>> I obviously agree, but take in account that this uWSGI plugin simplified
>> the steps a lot:
>>
>> https://github.com/unbit/uwsgi-sse-offload
>
>
> nice. it certainly looks cleaner than having an external gevent
> process. does it
Could you help me understand why this have to be done inside a web server
container?
When I've previously read about reasons for that they tend to be things
like "handling slow clients", something that an event loop is excellent at
automatically. To me, this means that this process could run ou
Hey Emil,
On Sunday, May 31, 2015 at 10:52:26 AM UTC+2, Emil Stenström wrote:
...
> Also, I don't think you would need to mix redis (or any other persistent
> storage) into this. The connected clients could simply be stored in an
> in-memory array, that is discarded if the server crashes. When
On Sun, May 31, 2015 at 3:52 AM, Emil Stenström wrote:
> Could you help me understand why this have to be done inside a web server
> container?
AFAICT, it doesn't have to be done in the container, but currently it
must be 'outside' of Django. But having help from the container
allows a single re
On Sunday, 31 May 2015 11:15:28 UTC+2, Federico Capoano wrote:
>
> On Sunday, May 31, 2015 at 10:52:26 AM UTC+2, Emil Stenström wrote:
> ...
>
>> Also, I don't think you would need to mix redis (or any other persistent
>> storage) into this. The connected clients could simply be stored in an
>>
On Sunday, 31 May 2015 11:16:17 UTC+2, Javier Guerra wrote:
>
> On Sun, May 31, 2015 at 3:52 AM, Emil Stenström >
> wrote:
> > Could you help me understand why this have to be done inside a web
> server
> > container?
>
> AFAICT, it doesn't have to be done in the container, but currently it
>
On Saturday, May 30, 2015 at 10:40:26 PM UTC+1, Emil Stenström wrote:
>
> Client A clicks a button on the site, that sends an normal ajax request to
> Django. In the view a message is passed from Django to the SSE process.
>
How, you still need some kind of interprocess communication
So the S
I'm going to kind of reiterate what Florian said.
The fact that you keep describing your idea as another process/thread that
has back and forth communication with the actual Django instance seems to
indicate to me that it's another program. I think people here tend to
follow more of the UNIX philo
On Sunday, 31 May 2015 16:52:50 UTC+2, Rotund wrote:
>
> The fact that you keep describing your idea as another process/thread that
> has back and forth communication with the actual Django instance seems to
> indicate to me that it's another program.
>
Yes, I was not clear about the distinctio
On Sunday, 31 May 2015 15:56:09 UTC+2, Florian Apolloner wrote:
>
> On Saturday, May 30, 2015 at 10:40:26 PM UTC+1, Emil Stenström wrote:
>>
>> Client A clicks a button on the site, that sends an normal ajax request
>> to Django. In the view a message is passed from Django to the SSE process.
>>
>
I think the real questions are:
1. What is stopping a 3rd party product from providing the features you
want?
If there is something Django can do to make it easier, point it out, and
I'll gladly champion a good feature.
2. Why should your solution be the "blessed" solution?
The discussion clear
Just to chime in here - I've long been in favour of some kind of support
for event-driven stuff inside Django, but as Curtis is saying, there's
nothing here that couldn't be done in a third party app first and then
proven there before any possible merge into core.
I also don't think that this prop
On Monday, 1 June 2015 01:42:38 UTC+2, Curtis Maloney wrote:
>
> I think the real questions are:
>
> 1. What is stopping a 3rd party product from providing the features you
> want?
>
Nothing as far as I see it. Will develop as a third part
> 2. Why should your solution be the "blessed" solu
Thanks for you reply Andrew,
On Monday, 1 June 2015 13:05:34 UTC+2, Andrew Godwin wrote:
>
> Just to chime in here - I've long been in favour of some kind of support
> for event-driven stuff inside Django, but as Curtis is saying, there's
> nothing here that couldn't be done in a third party app
Hi Emil,
I agree that there perhaps needs to be a more "pull" here than just making
a third party app, but I feel I can speak from a good place when I say
third party apps can absolutely prove core Django features in a way that
gives them much faster release cycles and freedom from things like LTS
Hi,
On Tuesday, 2 June 2015 11:25:14 UTC+2, Andrew Godwin wrote:
>
> Hi Emil,
>
> I agree that there perhaps needs to be a more "pull" here than just making
> a third party app, but I feel I can speak from a good place when I say
> third party apps can absolutely prove core Django features in a
Hi,
FWIW, here is how you can add real-time push to Django apps without
reinventing the world in Django (read: using blocking code):
http://crossbar.io/docs/Adding-Real-Time-to-Django-Applications/
This is using the HTTP/REST bridge services of Crossbar.io:
http://crossbar.io/docs/HTTP-Bridge-
24 matches
Mail list logo
