Finding (from the #1189 RN/Metro async review of PR #1346)
TowerClientOptions accepts host + port and the constructor hardcodes the scheme and shape: this.baseUrl = \http://${host}:${port}``. Two real deployment shapes cannot be expressed:
- The cloud tunnel proxy. Browser (and later mobile) access through Codev Cloud rides
https://<cloud-host>/t/<towerId>/...: https scheme, default port, and a path prefix. None of the three fit host+port+hardcoded-http. - Any TLS-terminated or reverse-proxied Tower (same structural problem).
This is Phase-2-blocking for mobile (cloud-connected mode is entirely proxy-based) and already constrains any web use of the sdk through the tunnel today.
Ask
Accept a full base URL as the alternative: baseUrl?: string (mutually exclusive with host/port, which remain the local-default convenience). URL building inside the client must then join paths against a possibly-prefixed base rather than assuming origin-rooted routes. The workspace-scoped route builders deserve a glance at the same time (they concatenate absolute paths today).
No behavior change for existing consumers; host/port keeps working.
Origin
Anticipated by the mobile handoff/auth designs (codev/research/mobile/decisions/q1-pairing-model.md, q2-auth-model.md: handoff URLs are tunnel-proxy paths) and surfaced concretely while reviewing the sdk constructor against those flows.
Finding (from the #1189 RN/Metro async review of PR #1346)
TowerClientOptionsacceptshost+portand the constructor hardcodes the scheme and shape:this.baseUrl = \http://${host}:${port}``. Two real deployment shapes cannot be expressed:https://<cloud-host>/t/<towerId>/...: https scheme, default port, and a path prefix. None of the three fit host+port+hardcoded-http.This is Phase-2-blocking for mobile (cloud-connected mode is entirely proxy-based) and already constrains any web use of the sdk through the tunnel today.
Ask
Accept a full base URL as the alternative:
baseUrl?: string(mutually exclusive with host/port, which remain the local-default convenience). URL building inside the client must then join paths against a possibly-prefixed base rather than assuming origin-rooted routes. The workspace-scoped route builders deserve a glance at the same time (they concatenate absolute paths today).No behavior change for existing consumers; host/port keeps working.
Origin
Anticipated by the mobile handoff/auth designs (
codev/research/mobile/decisions/q1-pairing-model.md,q2-auth-model.md: handoff URLs are tunnel-proxy paths) and surfaced concretely while reviewing the sdk constructor against those flows.