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 > user-group, perhaps someone else does. > > ok, back to the "sse only" discussion.........
> > > That is answering the question : "How does web2py keep a long-lasting > connection". > That is NOT answering the question: "How can a different controller-action > activate this" > Why does this have to be activated in another controller-action ? The point of SSE is that as soon as your page does the eventsource(url) stuff, the connection is istantiated and (reconnections aside) never closed. Sure, you can have your js code attaching/detaching to different urls, but you're going to increase the overall implementation weight. Inside that loop you can do, e.g. msg = db(db.messages.recipient == auth.user_id).select().first() yield msg it's just a simple example that shows that you how in the same loop you can be "influenced" by other actions (i.e. that have submitted a record to the messages table) > But it answers NONE of the questions I asked... > > There is *no inter-controller/action communication* in here, there is no > way to *POST* something *from the client to the server*, that will *call > a different action* in web2py, which will *then invoke another yield* of > the SSE action, thus* intentionally-spawning another response over the > existing connection....* > 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. > And what if there are multiple connections to multiple clients? the only > way to differentiate between them would be via their sessions. > Now, the way I understand this, it's a *fundamental "executional" * > limitation > of web2py - it has no concurrency, so each invocation of web2py's > wsgi-handler, is in fact a single-process-single-thread type of scenario, > so that there could never exist multiple sessions that are handled at the > same time.... > > No framework supports multiple connections in the same thread/coroutine/process. Every different implementation either spawns a process, or a thread, or a greenlet to do the work . Of course the more lightweight the better, so greenlets win hands down. That being said, web2py is obviously concurrent: no site will be deployed with web2py if that was in fact happening. Concurrency is achieved with threads with the default webserver, but anyone is posing a limit on what you want to run web2py into. I really don't see what's the missing component on web2py (aside not being able with rocket to support a lot of users with SSE). As soon as you run it in a gevent wsgiserver (or the usual gevented gunicorn) you can do whatever you want. In the loop you have to build your own routing, that is all is needed. -- --- 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 web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
