Last modified: 2014-06-05 09:21:46 UTC
Numerous *really cool things* in the future will depend on having infrastructure in place for sending real-time messages from the server to the front-end web pages (and vice-versa, though usually the upstream pings are an easier matter). A scalable system probably needs additional servers to handle the WebSockets (or comet/long-poll style HTTP for compat with existing browsers), but a basic or more limited stub implementation could go into a standard PHP core that would still be useful for many things on smaller sites. This may be more of a tracking bug for now. :)
(In reply to comment #0) > A scalable system probably needs additional servers to handle the WebSockets > (or comet/long-poll style HTTP for compat with existing browsers), We could write a client-side WebSockets layer that falls back to Comet if WebSockets aren't available. In fact, I'd be moderately surprised if something like that doesn't already exist. > but a basic > or more limited stub implementation could go into a standard PHP core that > would still be useful for many things on smaller sites. > ...and again, support two entry points (WebSockets and Comet) on the server side.
There are many such libraries yes. :)
RFC: https://www.mediawiki.org/wiki/Requests_for_comment/Structured_data_push_notification_support_for_recent_changes
This isn't an actionable bug, and its dependencies don't really make sense (is all that going to happen and have a common interface?). See also: * (bug 14045) Set up an easy to parse recentchanges feed > [[wikitech:stream.wikimedia.org]] > [[wikitech:RCStream]]
