GSOC 2014 - "Websockets" Project Interest

[Md. Ali Ahsan Rana]

Hi All,
I am a masters student at Concordia University, montreal, canada. I am
interested in the "Websockets" project that is listed on GSOC 2014 project
idea list.

I have checked the related project: http://socketo.me/ and seems to me the
approach could be:

1) Check whether server can offer opening new ports(which won't be possible
on shared servers etc).
2) If yes, dynamically create server to listen api calls. And set session
settings so that further API calls to be done here.

However, I am confused about few things:

* Does it required to be implemented as a modular independent plugin or as
a part of core?
* 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?

Wish to look forward to hear your feedbacks and further suggestions soon.

Regards

Rana

[Bryan Petty]

On Tue, Mar 11, 2014 at 1:40 PM, Md. Ali Ahsan Rana

Post by Md. Ali Ahsan Rana
* 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.

Post by Md. Ali Ahsan Rana
* 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

[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

Post by Bryan Petty
On Tue, Mar 11, 2014 at 1:40 PM, Md. Ali Ahsan Rana

Post by Md. Ali Ahsan Rana
* Does it required to be implemented as a modular independent plugin or

as

Post by Md. Ali Ahsan Rana
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.

Post by Md. Ali Ahsan Rana
* Which functionality/facility scope should be covered under this

websocket

Post by Md. Ali Ahsan Rana
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
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
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Md. Ali Ahsan Rana]

Hello Bryan/Eric,
I have made a draft application for the project here:
https://docs.google.com/document/d/1oB28xUdvA154JCvCioCha6wIP8otxnuoYuYk9J6Ylpk/edit?usp=sharing


I have also published the proposal part on my blog here:
http://codesamplez.com/websockets-plugin-for-wordpress

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'

Regards
Rana





On Thu, Mar 13, 2014 at 1:01 AM, Md. Ali Ahsan Rana

Post by 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

Post by Bryan Petty
On Tue, Mar 11, 2014 at 1:40 PM, Md. Ali Ahsan Rana

Post by Md. Ali Ahsan Rana
* Does it required to be implemented as a modular independent plugin or

as

Post by Md. Ali Ahsan Rana
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.

Post by Md. Ali Ahsan Rana
* Which functionality/facility scope should be covered under this

websocket

Post by Md. Ali Ahsan Rana
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
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
http://lists.automattic.com/mailman/listinfo/wp-hackers