GSOC 2014 - "Websockets" Project Interest

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: GSOC 2014 - "Websockets" Project Interest

Bryan Petty
On Tue, Mar 11, 2014 at 1:40 PM, Md. Ali Ahsan Rana
<[hidden email]> 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
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:

> On Tue, Mar 11, 2014 at 1:40 PM, Md. Ali Ahsan Rana
> <[hidden email]> 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
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: GSOC 2014 - "Websockets" Project Interest

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
<[hidden email]>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.
>
> Regards
> Rana
>
>
>
> On Tue, Mar 11, 2014 at 4:45 PM, Bryan Petty <[hidden email]> wrote:
>
>> On Tue, Mar 11, 2014 at 1:40 PM, Md. Ali Ahsan Rana
>> <[hidden email]> 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
>> [hidden email]
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
>
>
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers