Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

undefined var in html examples #3

Open
bhyde opened this issue Mar 23, 2014 · 7 comments
Open

undefined var in html examples #3

bhyde opened this issue Mar 23, 2014 · 7 comments

Comments

@bhyde
Copy link

bhyde commented Mar 23, 2014

The variable onramp appears in the html examples, but it is never declared or initialized.

For example in the walkthru

onrampServer.on('message', function(peerAddress){
  // 3. Connect to another browser which is 
  //    connected to the WebSocket server
  var peer = onramp.connect(peerAddress);
@unsetbit
Copy link
Owner

Thanks for reporting this, fixed!

@bhyde
Copy link
Author

bhyde commented Mar 23, 2014

The walk thru here: http://ozan.io/p/#/walkthrough is borked. I started by following that walk thru, but once i discovered https://github.com/oztu/p/tree/master/examples/ping-pong it became clear that things have changed. Connect takes a hash. The websocket announces new peers via 'connection' rather than 'message'. I probably have a better handle on what else has changed. :)

ps. I'm having fun, thanks.

@unsetbit unsetbit reopened this Mar 23, 2014
@unsetbit
Copy link
Owner

Ah, sorry, I had fixed it on the front page, but didn't realize the problem occurred elsewhere. I'll update accordingly.

@unsetbit
Copy link
Owner

Alright I've updated the walkthrough page as well, I still have to verify the cookbook page to make sure that's up-to-date so I'm going to keep this issue open until I do that.

@bhyde
Copy link
Author

bhyde commented Mar 24, 2014

Now I feel guilty about your weekend, give my apologies to your family. :)

@bhyde
Copy link
Author

bhyde commented Mar 24, 2014

I guess this is related, so I'll add it as a comment here. I'm a bit confused by the 'connection' event. What confuses me you ask? Here are the uses in the examples:

bash-3.2$ pwd
/Users/bhyde/w/p/examples
bash-3.2$ grep "on('connection" */*
party/Charlie.html: p.on('connection', function(peer){
party/alice.html:   onramp.on('connection', function(peer){
ping-pong/pong.html:    onramp.on('connection', function(peer){
bash-3.2$ 
  1. Why is Charlie's behavior is not like the others?
  2. Bob, curiously, has no connection handler at all ... that seems odd.
  3. Could I just put a connection handler on the P object, assuming I don't care who told me about this peer?
  4. It now seems obvious that I need to be robust in the face of multiple connection events for the same peer.
  5. I assume the reason that pong don't handle this event is that he can depend on the onramp message events inform them of all their peers. Which makes me wonder if those messages are redundant, and I could just depend on the connection messages?

@unsetbit
Copy link
Owner

unsetbit commented Jul 7, 2014

  1. Charlie is interesting in anyone connecting to him but he doesn't initiate communication with anyone (other than connecting to the onramp server, of course). By listening directly on 'p' instead of 'onramp', he's notified of any connection made to him, whether via the onramp or another peer (Bob, in this example).
  2. Bob listens for messages from the two onramps servers (the messages are peer addresses) and then he initiates the connection to them, which is why he doesn't have a connection handler. He's aware of all that's going to happen in this case (he's initiating the connections to both onramp servers, and bridging their connected peers together). Listening to the 'connection' event is a passive action, like when you're expecting a call.
  3. Yes, in fact, that's what Charlie is doing.
  4. Yes, connection events are fired at two points -- from the signaling server (such as the onramp object or the peer object for Bob) and from the root object ('p').
  5. The message events provide the addresses for pong to initiate a connection to. At least one of the peers has to make the connection attempt to the other peer. onramp is design to assign and broadcast addresses for peers connected to it, but you can signal the address for the peers via other ways as well (for example if ping's "address" was always "1" then pong would just do onramp.connect({address: '1'}) instead of waiting for the message. This assumes ping would always be available, of course.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants