[wp-hackers] GSOC 2014 - "Websockets" Project Interest
bryan at ibaku.net
Tue Mar 11 20:45:22 UTC 2014
On Tue, Mar 11, 2014 at 1:40 PM, Md. Ali Ahsan Rana
<aliahsanrana at gmail.com> wrote:
> * Does it required to be implemented as a modular independent plugin or as
> a part of core?
As you pointed out, most hosting environments won't be able to use it
at all. There's also client browsers that won't (including IE10
without flash installed).
That said, it would be implausible to redesign core components in a
way that absolutely relies on them. That's not to say they couldn't be
written in a way that allows them to take advantage of them assuming
you're able to effectively detect when both the server and client can
So I would definitely see this being developed as a plugin prototype
first, with the goal of providing an easy to use API that could
potentially let core features use it if it's available, but safely
fall back on traditional requests otherwise.
> * Which functionality/facility scope should be covered under this websocket
> feature? I guess, all remote api, ajax calls could be done easily. Am I
Current AJAX calls would certainly be the most obvious target for
optimization through this (especially the heartbeat API, which I think
may have considered WebSockets at one point), though it's probably a
lot harder than you think it is.
Something to keep in mind is that using WebSockets means that our
traditional PHP script lifecycle changes significantly. Specifically,
there will be cases where core API defines constants based on certain
requests and calls, and those constants need to *not* be defined for
additional WebSocket requests. WordPress is currently designed around
processing only one request at a time, knowing those constants will be
reset upon the next request. That won't be true for multiple WebSocket
You'll need to keep a close eye on where WordPress defines those
constants, and additionally anywhere it calls wp_die() - which would
also break the WebSocket connection.
That said, I'm sure you could still find good request type candidates
that aren't encumbered by those limitations, and could be easily roped
into a WebSocket workflow.
I'd also take a look at some existing WordPress plugins that already
use WebSockets for some inspiration. Here's a few I was able to find
quickly (I haven't looked at any of them):
More information about the wp-hackers