[wp-hackers] GSOC 2014 - "Websockets" Project Interest
Md. Ali Ahsan Rana
aliahsanrana at gmail.com
Sat Mar 15 05:05:23 UTC 2014
I have made a draft application for the project here:
I have also published the proposal part on my blog here:
Looking forward to get some feedbacks and suggestions about it.
Also I have few questions as well:
* I think for this plugin, there will be need for some administration
settings as well(like configuring port(s) to use etc) . Do you have any
suggestions about the possible configurable options?
* In the application template, the 'Schedule of Deliverables' , is it OK to
put some rough estimation or if its required some preliminary discussion
with mentor, can I get your IRC handle please? I am with nick 'AliAhsanRana'
On Thu, Mar 13, 2014 at 1:01 AM, Md. Ali Ahsan Rana
<aliahsanrana at gmail.com>wrote:
> Hello Bryan,
> Thanks for your valuable feedbacks. I forgot about the browser/client side
> compatibility. About the implementation part, I will follow the approach
> you suggested and also thanks for those nice tips. I am also checking with
> the plugin links you given. I will start preparing the proposal and get
> back if I need any further clarifications.
> On Tue, Mar 11, 2014 at 4:45 PM, Bryan Petty <bryan at ibaku.net> wrote:
>> 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
>> > 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
>> support it.
>> 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
>> > feature? I guess, all remote api, ajax calls could be done easily. Am I
>> > wrong?
>> 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):
>> Bryan Petty
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
More information about the wp-hackers