-
Notifications
You must be signed in to change notification settings - Fork 15
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
Add remote control without wifi / "Shabad OS Connect" #416
Comments
Main spec points needed are:
|
|
We should expose this functionality in the API |
Interesting. So the options we have are:
Leaning towards 1 actually. With a refresh button to regenerate the PIN. If we can get that to work over our current setup, it should just seamlessly tie-in when we add remote. Related #24.
Here's the way I see it: Shabad OS connect will effectively form a tunnel to the host. That means you'll be able to do everything you could do if you were on the same network, including the different endpoints. I reckon this approach is best, and then the idea of a reader view for mobile devices, we should probably just add that to the app for local users/readers anyway (we used to have the Kobo endpoint).
Certainly. Though I'm of the opinion that it's totally unrelated to the data stuff, so we can just open up a new repo and create a microservice that handles anything to do with connect. |
So example of the website shabados.com/156484 (random 6 digits) and then the endpoints added on the end like shabados.com/156484/overlay ? What is hosted on our servers vs being served by the host device? From a practical example:
This is also fine. I was thinking it would be one less step for the user if it were combined as a write code which changes on each start up. So instead of the 6 digit read code they just input the 6 digit write code as the URL and it gives you control. Instead of having to add some way for the user to put in a PIN after typing in the read code. Could maybe make it so the PIN is added on to the read code? So it's like 156484 is the read and 23 is the write so it becomes 15648423 to write? |
Exactly
Session server - host device The code is received by the connect API, and then it provides a HTTP + WebSocket connection/relay to the host device.
It might actually just be less tedious to have the link sent over to the mobile device etc. But actually, if we had a write code, does this not conflict with having a PIN too? Or cause confusion? It depends on how the PIN code would be entered normally on the local network. Maybe a write code could automatically enter the PIN. It’s possible to have it in the URL like that, though not sure if it’s a good idea yet. I think it’d be ok to include it in query parameters |
Having the link sent is the least tedious method. If the pin is shown in the url as a parameter it's kind of the same as sending it as a write code. Either way allows user to easily connect to write with one url. The PIN does not work alongside the write code. It's one or the other. So you always have a read code. So the question is do you want a separate code for write access or do you want a pin on top of the read to gain write access? I think a separate write code is easier, since we're not running out of codes any time soon haha. In the off chance they have to type it manually and don't have the link sent to them. But again, either way is fine. Estimated time to develop? This would be related to hukamnama issue spec if someone wants to access the overlay/hukamnama from a different wifi or cloud service. |
So would this work?
|
Rough work required:
|
@Harjot1Singh @bhajneet interesting conversation thanks for looking into it. Is there provision for a broadcast computer running shabad os and then a projector computer that e.g. Is old, doesn't have Internet for us to come in, with a wifi hotpot, open a browser, save us from installing and opening a display with full display settings capability? (Not just overlay) |
@preetcharan yeah, this proposal would support your scenario. Basically, you'd be able to access all current Shabad OS facilities as if on the local network in the first place |
1 and 2 obviously fine.
Could be you want some website or whatever our online browser version of connect would be to somehow point you to a local IP address if it detects you're on the same network. In that case you would have to add a read / write mode of IP addresses for point 3. But I'm not sure what the point of connecting locally this way would be? |
Add some kind of method to connect and control Shabad OS without the wifi. So basically what we already allow with browsers on the network, but without the network part...
Allows multiple streamers to pull captioning from one central shabad os without requiring all streamers to share gurdwara internet bandwidth
Allows users to remote control shabad os when the gurdwara wifi is locked down (passwords not shared)
Allows elderly people to connect for reader purposes again in the same scenario above where the wifi is not shared in gurdwaras or is set up by non gurdwara committee members.
Allows people to follow along on live streams started on phones (so facebook / youtube for smartphones) where captioning isn't available.
Will be needed for mobile app anyways. Part of the idea of "Connnect to Shabad OS Nearby" or via some ID. Can use 4 non-ambiguous upper case letters (24) to get about 24^4 = 330k unique ids. I doubt that we will have that many concurrent users, but can always go for 3 pairs of numbers which is a million unique IDs.
Marking it high since it will be used in the future for a second project. Marking it "in research" to try and spec it out before any work is done. So if you have any UI questions or user flows, let's figure it out here first.
The text was updated successfully, but these errors were encountered: