On Wednesday, April 10, 2013 12:53:01 AM UTC+2, Arnon Marcus wrote:
Well, again, Redis IS required for inter-controller communication... (the
notorious green arrows in my picture...) Which is, to me, a trivial
requirement for most production use-cases...
I use redis too in standard
On Tuesday, April 9, 2013 12:50:42 AM UTC+3, Paolo Caruccio wrote:
When I wrote the small app SSE_clock I was searching a replacement for a
long polling javascript code that I was using in order to push db's table
update notifications to clients. I abandoned the project by lack of
the subscribe part is a method that listens blocking and resumes as
soon as a message is received (so, it blocks if there are no new messages
until there is a new one)
so, in your SSE action you should do something like (pseudo-code)
Yup. That's my point - without gEven, it would be
ok, all clear!
One point though: with a threaded webserver web2py can manage as many
connections as there are free threads: it's not blocking everything at the
first SSE yielding loop, it doesn't communicate with new connections as
soon as there are n open connections, with n == max number of
The first yield WILL block the thread, but as you say, only the thread of
that connection. So the inter-thread communication would then be solved via
another shared process - Redis - which will act as a message broker,
listening to submissions and submit publications for subscribers.
I guess I can
just a crazy question: what about if you wrap the eventsource in a web
worker?
Il giorno martedì 9 aprile 2013 22:56:51 UTC+2, Arnon Marcus ha scritto:
The first yield WILL block the thread, but as you say, only the thread of
that connection. So the inter-thread communication would then be
On Tuesday, April 9, 2013 10:56:51 PM UTC+2, Arnon Marcus wrote:
The first yield WILL block the thread, but as you say, only the thread of
that connection. So the inter-thread communication would then be solved via
another shared process - Redis - which will act as a message broker,
Well, again, Redis IS required for inter-controller communication... (the
notorious green arrows in my picture...) Which is, to me, a trivial
requirement for most production use-cases...
So, to sum-up :
- For inter-controller communications, you need an external message-broker
(Redis/RabbitMQ).
-
On Tuesday, April 9, 2013 2:50:41 PM UTC-7, Paolo Caruccio wrote:
just a crazy question: what about if you wrap the eventsource in a web
worker?
Not sure I'm following you on this one...
How would that help?
The browser is already a non-blocking event-machine...
Web-workers are not aimed
You said that the commet-thing is no longer existing, as websockets where
already included in web2py.js, which as I remember correctly is referenced
in the main application layout. But what about SSE? I mean, sure, it's just
an HTTP request, at start, but there is a different model for
Nope, or maybe I expressed myself badly: that implementations started
named as comet messaging but turned to websocket messaging at the first
iteration.
web2py.js has an usable implementation for it and
gluon/contrib/websocket_messaging.py is 200 lines of which 70 are comments,
it's
Oh, and I forgot the most important aspect:
How can an active submission-action of user A, *locate *the correct
session that holds the correct SSE-connection of user B? And how can it use
that SSE-action *with *that session of user B?
--
---
You received this message because you are
As I said, I've already gone over the websocket_messaging.py file - it
has dealings with WebSockets - NOT SSE (!) - and via Tornado, NOT web2py...
We all got that. it's an external process, but it's implemented already, it
just works, has a simple yet powerful routing algo and its secure.
Look, I appreciate you're trying to help-out, but it seems you are
answering the questions you know the answers to, instead of the questions I
ask.
It's OK to say that you don't know the answer. You are not alone in this
user-group, perhaps someone else does.
We all got that. it's an external
The reason this capability is useless, is that it limits the usage of SSE
connection way too much...
There is no reason I would have to stick my entire code for dealing with
updates to a section of my app, within a single action...
It makes no sense at all...
If I have an action that updates
On Monday, April 8, 2013 5:48:31 PM UTC+2, Arnon Marcus wrote:
Look, I appreciate you're trying to help-out, but it seems you are
answering the questions you know the answers to, instead of the questions I
ask.
It's OK to say that you don't know the answer. You are not alone in this
oh my SSE are unidirectional, so of course the example shows you just
the server -- client part and not the client--server one.
you can do the client-- server part as usual with an ajax post.
(I would appreciate you refrain from using expressions with
condescending implications such
That's what I'm talking about... :)
http://vimeo.com/41410528
And this is from 2011...
When will web2py support 0MQ ???
Ach...
Can web2py subscribe to Redis publishing?
--
---
You received this message because you are subscribed to the Google Groups
web2py-users group.
To unsubscribe
On Monday, April 8, 2013 7:11:57 PM UTC+2, Arnon Marcus wrote:
oh my SSE are unidirectional, so of course the example shows you just
the server -- client part and not the client--server one.
you can do the client-- server part as usual with an ajax post.
(I would appreciate you
I think a picture is worth more than a thousand words... ;)
Thanks for clearing it out - I get it now. It is still disappointing that
the only way to do that is by polling... It's not solving the problem,
just moving it around. It's fundamentally (in terms of execution-model),
not different
When I wrote the small app SSE_clock I was searching a replacement for a
long polling javascript code that I was using in order to push db's table
update notifications to clients. I abandoned the project by lack of
browser's support.
Anyway, the application is a simple translation from php to
ok, we are getting closer! ^__^
Thanks for clearing it out - I get it now. It is still disappointing that
the only way to do that is by polling... It's not solving the problem,
just moving it around. It's fundamentally (in terms of execution-model),
not different than using long-polling in
I will elaborate.
I have 2 different interest:
The first one has to do with my personal feeling of understanding the
inner-workings of the implementation of messaging options in web2py, on the
architectural level. I do NOT want to re-invent the weal by any means, but
I do want to understand
As for the Tornado-web-socket example, I looked at the code, and couldn't
figure out how this would work in a production environment...
Does it spawn a separate python interpreter for Tornado?
If so, how does it meld with we2py's controllers? It is unclear how this
works...
What serves the
On Sunday, April 7, 2013 1:51:11 PM UTC+2, Arnon Marcus wrote:
As for the Tornado-web-socket example, I looked at the code, and couldn't
figure out how this would work in a production environment...
Does it spawn a separate python interpreter for Tornado?
yes, it's very clear that there
10x Niphlod
Have you read my previous comment? the one just before the one you
commented on?
--
---
You received this message because you are subscribed to the Google Groups
web2py-users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
yep, but you clearly have just started documenting and have a lot of ideas
going around.
as far as message passing between processes is concerned, you mentioned a
lot of good players.
as far as message passing in a web application, there are not so many:
- ajax (bi-directional, long-polling)
-
How about engine.io? or SockJS?
Most libraries have fallbacks/pollifills/shims or whatever...
The thing is, it seems I would need some kind of centralized broker, if I
want to share the messaging code across all use-cases, and I DO want the
messages committed, in most cases, so I am not looking
On Sunday, April 7, 2013 6:25:06 PM UTC+2, Arnon Marcus wrote:
How about engine.io? or SockJS?
as I was saying, you're reading too much too soon, just naming buzzwords
without actually **thinking** to what you need.
Engine.io is just the protocol for socket.io.
Sockjs is another
Don't wan't to start a flame-fest, but I feel like I am under fire here,
and unjustly so...
as I was saying, you're reading too much too soon, just naming buzzwords
without actually **thinking** to what you need.
I admit I don't have experience with many of the things I was writing
about,
Here is an interesting presentation I am currently watching, describing a
messaging architecture using ZeroMQ + Redis :
http://www.youtube.com/watch?v=Z-4EqEZbfBM
--
---
You received this message because you are subscribed to the Google Groups
web2py-users group.
To unsubscribe from this
On Sunday, April 7, 2013 9:23:16 PM UTC+2, Arnon Marcus wrote:
Don't wan't to start a flame-fest, but I feel like I am under fire here,
and unjustly so...
I was not trying too, I'm just noticing how much this discussion is
starting to involve a lot of things that are offtopic. It's one
I was not trying too, I'm just noticing how much this discussion is
starting to involve a lot of things that are offtopic. It's one thing
searching for answer (and expecting them) on a specific topic and another
one to try to follow every bit of your proposed
Wow. It's cool that web2py ships with a websockets implementation. I was
also thinking like Arnon about how to implement server-sent events with
web2py.
As such I do want to add, maybe for posterity sake, that websockets serve a
different use case than server-sent events, and are more
1. How? Usually by a yield somewhere. Where? The already existing open
connection knows where.
2. Slow down there, you're overthinking it. Web2py comes with this.
Look at web2py/gluon*/contrib/*comet_messaging.py
And...
watch this video by Bruno Rocha
http://vimeo.com/18399381
On Thursday,
35 matches
Mail list logo
