We don't have a way to update the playlist.

turbowookie / turbo-wookie

Turbo Wookie Project. Because Turbo Wookie

http://turbowookie.github.io

BSD 3-Clause "New" or "Revised" License

9 stars 2 forks source link

We don't have a way to update the playlist. #15

Closed mpeterson2 closed 10 years ago

mpeterson2 commented 10 years ago

When a user updates the playlist, we can easily just go to the server and request the server to get an updated playlist.

When we have multiple users connected, the extra users will not get the update.

We have a few options.

Have the clients request updates from the playlist every few seconds (10 seconds or so).
Do more work and have the client subscribe to a stream where the server will send updates to the playlist when it needs to. This shouldn't be hard on the client side, but I'm not sure about the server side.

sleepdeprecation commented 10 years ago

Doesn't the stream tell you things? Aren't there different events that happen? Don't you have a bunch of listeners?

What I'm getting at is: is it possible the stream already tells us when things change? Like maybe onUpdate or something.

The best solution is two; have there be some sort of observer-esque thing going on between the client and server. I was looking at what we get in the http.Request given to all our HandlerFuncs, and we have access to the underlying TCP object, which means we might be able to hang onto that, and ping it whenever something changes... And considering we now have a thing running in the background, telling us when it changes (and even if we didn't, we have a server object now), sending something down that pipe shouldn't be too difficult.

mpeterson2 commented 10 years ago

I don't think the stream can tell us that the playlist updated. I'll look at it and see though.

sleepdeprecation commented 10 years ago

I'm not entirely sure what it sends...

mpeterson2 commented 10 years ago

Nope. Nothing special happens when we add something to the stream.

I did make the first solution a thing so we at least have something. I also wrote out what I think the second solution will be and commented it out. I'm going to push that now.

sleepdeprecation commented 10 years ago

I think we might be able to something similar to a Long-Poll Server.

Basically we fake it, kinda. A standard HTTP connection is made to the server when we start the client, and the server doesn't send anything back until some change happens. When a change happens, the server just tells the client something changed (we could specify the specific thing that changed, but I don't think we should send the changes over there, because we might have a host of different things that could change).

After the client receives the simple "things changed" message, they open up another connection like the last one, it just waits for the server to tell it something changed.

It's similar to an observer pattern, but we can't close the connection between messages because the server has no way of getting back to the client after that's done.

The key here is that we need to make sure the client doesn't time out, because it might...

I'm peeved with the lack of indentation used in the linked examples.

mpeterson2 commented 10 years ago

We fixed this with Don's idea above.