Websocket PID #98

Closed
francois2metz opened this Issue Mar 15, 2012 · 6 comments

Comments

Projects
None yet
4 participants
@francois2metz
Contributor

francois2metz commented Mar 15, 2012

I want to use websockets to be able to push updates as soon as possible. But with the current implementation of websockets, we need to know the PID of the websocket controller. This PID is only available when we receive a message.

A solution would be to call handle_message with open param. What do you think about it?

@vinoski

This comment has been minimized.

Show comment
Hide comment
@vinoski

vinoski Mar 15, 2012

Collaborator

Adding an open message is a possibility. Looking into it.

Collaborator

vinoski commented Mar 15, 2012

Adding an open message is a possibility. Looking into it.

@francois2metz

This comment has been minimized.

Show comment
Hide comment
@francois2metz

francois2metz Mar 15, 2012

Contributor

I started to implement my initial proposition, but in facts it doesn't resolve my issue. We need an API similar to streamcontent.

Contributor

francois2metz commented Mar 15, 2012

I started to implement my initial proposition, but in facts it doesn't resolve my issue. We need an API similar to streamcontent.

@jbothma

This comment has been minimized.

Show comment
Hide comment
@jbothma

jbothma Mar 16, 2012

Contributor

I started to implement my initial proposition, but in facts it doesn't resolve my issue. We need an API similar to streamcontent.

Your solution makes sense and I thought it does solve your problem. Although calling it handle_open would be more correct. handle_message({close, }) relates to a WebSocket close message, while open is an open event.

You'll have some backend that is triggering whatever you want to send to your clients. Each open callback could pass the websocket owner process Pid for the backend to store somewhere.

handle_open( something like Arg#) ->
register_pid_with_something(self()),
ok.

I'm not very familiar with streamcontent but it seems like you have to do the same kind of thing with "The Pid must typically be passed (somehow) to the producer of the stream." in http://yaws.hyber.org/yman.yaws?page=yaws_api

You probably need to remove Pids from your backend when the connection closes, and I'm not sure if handle_message({close, ...}) gets called if the socket fails (as opposed to a close WebSocket message)

You can achieve all of the above (except removing Pids) right now by making your javascript send a message on the open event, as in https://github.com/klacke/yaws/blob/master/www/websockets_example.yaws#L37

Contributor

jbothma commented Mar 16, 2012

I started to implement my initial proposition, but in facts it doesn't resolve my issue. We need an API similar to streamcontent.

Your solution makes sense and I thought it does solve your problem. Although calling it handle_open would be more correct. handle_message({close, }) relates to a WebSocket close message, while open is an open event.

You'll have some backend that is triggering whatever you want to send to your clients. Each open callback could pass the websocket owner process Pid for the backend to store somewhere.

handle_open( something like Arg#) ->
register_pid_with_something(self()),
ok.

I'm not very familiar with streamcontent but it seems like you have to do the same kind of thing with "The Pid must typically be passed (somehow) to the producer of the stream." in http://yaws.hyber.org/yman.yaws?page=yaws_api

You probably need to remove Pids from your backend when the connection closes, and I'm not sure if handle_message({close, ...}) gets called if the socket fails (as opposed to a close WebSocket message)

You can achieve all of the above (except removing Pids) right now by making your javascript send a message on the open event, as in https://github.com/klacke/yaws/blob/master/www/websockets_example.yaws#L37

@francois2metz

This comment has been minimized.

Show comment
Hide comment
@francois2metz

francois2metz Mar 16, 2012

Contributor

The name of the open callback is an ongoing topic. So let's move to another name.

For now even when the client send a message when the connection is opened, we are loosing the initial context. For example I authenticate the user before the upgrade to websocket. After the upgrade, I only have a pid without any other information.

So we can at least pass #Arg on the open callback, or something more open similar to gen_*:start_link args.

Contributor

francois2metz commented Mar 16, 2012

The name of the open callback is an ongoing topic. So let's move to another name.

For now even when the client send a message when the connection is opened, we are loosing the initial context. For example I authenticate the user before the upgrade to websocket. After the upgrade, I only have a pid without any other information.

So we can at least pass #Arg on the open callback, or something more open similar to gen_*:start_link args.

@jbothma

This comment has been minimized.

Show comment
Hide comment
@jbothma

jbothma Mar 16, 2012

Contributor

IIRC the WS handshake request can include a cookie, if it's on the same domain of course. If that isn't already in Arg it could be good to also make that available.

So yeah, your new parameter makes sense for telling your backend about client context, and it's handy to be able to pass some arbitrary parameter all the way from out() as you suggested.

I'm not sure about whether compatibility should be maintained when adding such a paramter.

Contributor

jbothma commented Mar 16, 2012

IIRC the WS handshake request can include a cookie, if it's on the same domain of course. If that isn't already in Arg it could be good to also make that available.

So yeah, your new parameter makes sense for telling your backend about client context, and it's handy to be able to pass some arbitrary parameter all the way from out() as you suggested.

I'm not sure about whether compatibility should be maintained when adding such a paramter.

@capflam

This comment has been minimized.

Show comment
Hide comment
@capflam

capflam Feb 18, 2013

Collaborator

Now, callback modules can define some optional functions to keep an internal state between calls, like gen_* modules. See the issue #99 and the commit 29a7989 for details.

Thanks

Collaborator

capflam commented Feb 18, 2013

Now, callback modules can define some optional functions to keep an internal state between calls, like gen_* modules. See the issue #99 and the commit 29a7989 for details.

Thanks

@capflam capflam closed this Feb 18, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment