We talked about this on yesterday's call..
Given a cloud name/number, I can ask a registry/discovery service for the "normal" XDI endpoint.
How do I find the WebSocket endpoint for that same cloud name/number.?
Options:
1. Also find it from the registry/discovery service, i.e. it's a separate <$uri> entry.
Advantage: Parallel to what we're doing for the "normal" XDI endpoint.
Disadvantage: Registry/discovery service has to hold more information, and if the WebSocket endpoint changes, you have to update the registry/discovery service(s).
2. Find the "normal" XDI endpoint, then from there find the WebSocket endpoint.
Advantage: The information comes from your own XDI graph. Registry/discovery service only has to hold minimal amount of information.
Disadvantage: Two round-trips required.
Advantage: Only one URI has to be registered for both bindings.
Disadvantage: Less flexibility, i.e. host and port must be the same.
Same question applies to the Browser binding, where we need to discover the URI of the web-based auth service. In this case we've been using option #2 so far.