Author here. The point of the design is that I'm treating the Pi as the display server (i.e. the client, or X11). The smartphone is the app-server because it hosts the relevant state.
The reason it's structured this way is that we want the ability to push code, logic, and data to the endpoint and have the endpoint execute it.
Consider a traditional usage scenario: your computer is the display server (web client), and the app server sits somewhere out on the cloud. The app server holds the application and the state, and you download it on the fly. The client (browser on your PC) is largely stateless, and the cloud-based server is the state carrier that ships both logic (in the form of a webpage + js) and data to the client on an as-needed basis.
In this design, the thing that's stateless is the endpoint (the thing connected to the TV). The state-carrier is the phone. The state-carrier needs to send logic and data to the client so that the client can execute it locally. This approach is in fact very natural.
Now, as you note, the actual transport details can be flexible. We _could_ design it so that the transport is handled by a small proxy that runs on the Pi. The proxy would be started when the browser session is initiated, and both the browser and the phone would connect to the proxy, and the proxy would act as mediator. But that would be an implementation detail. In the abstract, the phone would still be the server and the endpoint (the pi) would still be the client.
Fundamentally, we're starting an application on the phone, and sending parts of it to the pi for the pi to execute. The most natural model for that is for the phone to be the HTTP server (the state and logic originator) and for the pi to be the web client (the stateless device).
It's a bit counterintuitive, but if you think about it for a bit, it starts fitting together really well.
Thanks for the clarification. I think the point of confusion for me was around the word "endpoint". As a web developer, I'm so used to thinking of the phone as the "endpoint" that the notion of the phone as the app server threw me a little.
One other concern I have is input lag. You mention gaming, which can require some pretty precise input timing. Have you run into any issues around that? Or are modern wifi network generally Good Enough that lag isn't a problem?
I only had enough time to whip up the quick demo here. The responsiveness is pretty tight as far as latency goes - it "feels" like the photo on screen moves in tandem with the one under my fingers. No perceptible lag.
I wanted to try out some more interesting demos. One idea I had was to run the HexGL racing game (http://hexgl.bkcore.com/) on the endpoint, and then have the app on the phone interpret the gyro as steering and send it over to the endpoint.
However, I found that WebGL on the pi is slooooow, for both Chrome and Firefox. I don't think this is a raw power issue so much as using desktop browsers on a mobile device, where the browsers haven't been compiled with driver support for the graphics chipset (the Pi can run Minecraft just fine, so it should be able to handle a simple racing game).
My educated guess (from just the photo-viewing demo) is that the latency is good enough to support responsive gaming input.
Comments
Author here. The point of the design is that I'm treating the Pi as the display server (i.e. the client, or X11). The smartphone is the app-server because it hosts the relevant state.
The reason it's structured this way is that we want the ability to push code, logic, and data to the endpoint and have the endpoint execute it.
Consider a traditional usage scenario: your computer is the display server (web client), and the app server sits somewhere out on the cloud. The app server holds the application and the state, and you download it on the fly. The client (browser on your PC) is largely stateless, and the cloud-based server is the state carrier that ships both logic (in the form of a webpage + js) and data to the client on an as-needed basis.
In this design, the thing that's stateless is the endpoint (the thing connected to the TV). The state-carrier is the phone. The state-carrier needs to send logic and data to the client so that the client can execute it locally. This approach is in fact very natural.
Now, as you note, the actual transport details can be flexible. We _could_ design it so that the transport is handled by a small proxy that runs on the Pi. The proxy would be started when the browser session is initiated, and both the browser and the phone would connect to the proxy, and the proxy would act as mediator. But that would be an implementation detail. In the abstract, the phone would still be the server and the endpoint (the pi) would still be the client.
Fundamentally, we're starting an application on the phone, and sending parts of it to the pi for the pi to execute. The most natural model for that is for the phone to be the HTTP server (the state and logic originator) and for the pi to be the web client (the stateless device).
It's a bit counterintuitive, but if you think about it for a bit, it starts fitting together really well.
Thanks for the clarification. I think the point of confusion for me was around the word "endpoint". As a web developer, I'm so used to thinking of the phone as the "endpoint" that the notion of the phone as the app server threw me a little.
One other concern I have is input lag. You mention gaming, which can require some pretty precise input timing. Have you run into any issues around that? Or are modern wifi network generally Good Enough that lag isn't a problem?
I only had enough time to whip up the quick demo here. The responsiveness is pretty tight as far as latency goes - it "feels" like the photo on screen moves in tandem with the one under my fingers. No perceptible lag.
I wanted to try out some more interesting demos. One idea I had was to run the HexGL racing game (http://hexgl.bkcore.com/) on the endpoint, and then have the app on the phone interpret the gyro as steering and send it over to the endpoint.
However, I found that WebGL on the pi is slooooow, for both Chrome and Firefox. I don't think this is a raw power issue so much as using desktop browsers on a mobile device, where the browsers haven't been compiled with driver support for the graphics chipset (the Pi can run Minecraft just fine, so it should be able to handle a simple racing game).
My educated guess (from just the photo-viewing demo) is that the latency is good enough to support responsive gaming input.