It sounds like this is what you're trying to do: http://www.ape-project.org/
My understanding is limited, but I'll try to explain it. The basic structure is: * A normal web server for synchronous content (ie apache). * An asynchronous web server (like Tornado or Ape) to push events. * A state management system (like a database, separate daemon, or a file) to handle the inter-process communication. Events happen on your system (like someone posting a message or uploading a file) that have to be communicated back to the user. As the events occur they create entries in the database. The asynchronous server will keep a request open for a long duration to the client. While the request is open, the server is constantly checking the database for events. When an event occurs, the asynchronous server responds to the request with the event data. If no event occurs during the duration for the request, the request times out. After a request is completed, another request is made ad infinitum. Using this mechanism, it seems to the user that events are happening in real time (which is almost true). However, your client doesn't have to constantly poll the server to make that happen; actual traffic only occurs when you start a request and when a request terminates (which is an interval you control). On Feb 13, 6:27 am, Graham Dumpleton <[email protected]> wrote: > On 13 February 2010 07:28, till amon <[email protected]> wrote: > > > Thanks for your interest and of course i don't mind. > > > Atm i'm doing something like a chatroom-on-steroids, mainly to get a > > grasp on the various web technologies around. > > > So if i have one process that propagates update information around > > ( people join, leave , post ... ) > > there is basicaly one thread for each user, that accepts an incoming > > ajaxy request and then sleeps until there is any state change to send > > back. > > > So if i had a second process handling file uploads i would like to > > notify the first process upon completion of the upload with as little > > overhead as possible, which would then trigger all those sleeping > > threads to send the update information. > > May be too heavy, but use an XML-RPC call to call back from one > process to the other. > > BTW, having one thread per user itself may not be a good idea as it > will not scale very well. You should look at event driven systems > instead. There are various Python web servers designed specifically > for asynchronous model which can handle high concurrency without > threads. Have a look at Tornado as the current poster child. > > Graham > > > ( don't know. can databases send out asynchronus events these > > days ? ) > > > ... erm its not really about whether it makes a lot of sense. more > > about testing how much responsiveness can be squeezed out of this > > xmlhttprequest everyone seems so crazy about these days, and which > > design to use for that. > > > Therefor the rather aimless question for direction. > > I'm not that firm with the web yet, any hint would be appreciated. > > > cheers > > > On Feb 12, 8:35 pm, Rishi Ramraj <[email protected]> wrote: > >> From what I understand, state information for web apps is usually > >> stored in databases. What are you trying to do, if you don't mind me > >> asking? > > >> On Feb 12, 10:09 am, till amon <[email protected]> wrote: > > >> > Hello all, > >> > and apologies upfront for going to be vague. > > >> > i'm toying with mod_wsgi for a couple of days now and still am > >> > somewhat struck when it comes to threading semantics - especially how > >> > to share state between processes. > > >> > the current setup is like this : > >> > WSGIDaemonProcess daemon_group processes=1 threads=15 > > >> > Which is working fine as long as there is only one process. > >> > now to the vague part : if one wants to have other processes serving > >> > different scripts , what would be the cleanest way to share state > >> > among them if responsiveness was the main concern ? > > >> > (starting a 16th thread to wait for a unix pipe or socket does not > >> > seem to work - by design i guess ? ) > > > -- > > You received this message because you are subscribed to the Google Groups > > "modwsgi" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/modwsgi?hl=en. -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
