[wp-hackers] GSOC 2014 - "Websockets" Project Interest

[Md. Ali Ahsan Rana]

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.

Regards
Rana



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
> 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
> 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
> websocket
> > 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
> requests.
>
> 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):
>
> https://wordpress.org/plugins/bowob/
> https://wordpress.org/plugins/fcchat/
> https://wordpress.org/plugins/related-content-by-wordnik/
>
> Regards,
> Bryan Petty
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>