-
Notifications
You must be signed in to change notification settings - Fork 56
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
The web platform needs a service discovery mechanism #240
Comments
Over the last month or so I've been working on a PoC on "open discovery" for the Web: Not sure if this is along the lines you were thinking and would be happy to share my code and other notes with anyone who might be interested. |
@plinss to write up a blog post about service discovery, submit to w3c strategy funnel |
@larsgk might be interested |
I'd be interested in this. been working on a service-level discovery pattern for open web here: http://www.open-disco.org/. |
Second Screen CG has been working on the Open Screen Protocol https://webscreens.github.io/openscreenprotocol/ for devices that can render web content like Internet-connected TVs, HDMI dongles. OSP-compliant devices use DNS-SD over mDNS to find each other, QUIC for transport and metadata discovery. The spec is now considered ”feature complete” CG draft and is being prepared for TAG review. We have F2F https://www.w3.org/wiki/Second_Screen/Meetings/May_2019_F2F tomorrow, so I’ll put this issue on the F2F agenda. @mfoltzgoogle would be a key contributor to this proposed TPAC breakout session. |
Thanks @hadleybeeman, I'm certainly interested. |
Thanks @kenchris - VERY relevant, thanks! |
Just to be clear, the part that this touches on is the hardcoded part in section 3 in the OSP spec. I’m not particularly thrilled about exposing mDNS (with all it’s quirks) over the web platform, but it is indeed a viable option since it has extremely wide adoption. (We previously attempted this in the past with NFD spec, but I don’t consider that a success.) What we would like to see come out of the discussion is the following:
Do note that this is not a place where we are gathering proposals, it’s more of a architectural concern issue where we want to not do N inconsistent API patterns, and end up with a pile of regret later. We mentioned media because it feels like the most immediately use case which can benefit from this - as a immediate example, Plex does a lot of interesting (en_UK interesting) things to work around this not being available; so there is a clear need. Should we setup a separate call to discuss if this is worth a plenary breakout during TPAC later this year? |
On top of this, discovery mechanism should ideally have measures to avoid doing "service scanning", like by poking too much in well-known URIs, something equivalent to port scanning. |
Discussed today possible outcomes of this issue since the TAG likely won't itself take up work in this area. We discussed raising a process issue, raising it to the team, other options... |
Let me try to find out what happened with this https://developer.chrome.com/docs/extensions/reference/mdns/ - might be a start. (on non-TAG capacity) |
We discussed this at our W3CTAG Moon base alpha face-to-face. We agreed that this work should be incubated in a community group. @plinss has taken on that task. I will set this this to proposed closing, and we intend to close it when the CG is spun up and the discussion can move there. |
CG proposed looking for supporters... |
CG created |
While reviewing #237 in the Tokyo F2F, it came to our attention that the platform lacks a good mechanism for service discovery.
One of the ideas that came out of the discussion was to look into what the .well-known "bootstrapping" is attempting to solve, and prototype some of the ideas we had on top of DNS SRV records. (and possibly publish as a finding?)
The text was updated successfully, but these errors were encountered: