I have been thinking about other transport mechanisms (other than iframe) that would be interesting to see working with UCWA and two immediately came to mind: SignalR and NodeJS. Each can be used to work around the issue of cross-domain requests and provide additional pathways to access UCWA in the event that iframe communication is not feasible.
I was able to reuse a subset of the helper libraries I made in my previous .NET efforts, specifically Transport and some helper functions. The only modifications that seemed necessary were changes to the Response object as this would be directly used by the other sample libraries. I also wanted to avoid making modifications to the sample libraries beyond choosing between using iframe or SignalR.
The samples libraries' Transport.js needed modifications to support using SignalR over iframe. Modifications were made to allow Transport to take a hub Url (location of the hub proxy) upon construction. Presence of a hub Url is used to determine if Transport should create/connect to the hub proxy (injectFrame(...)) and how to send the request (clientRequest(...)). Similar to how event handlers for onmessage/message were attached/removed a function for handling the response callback was added to attach/remove handler per clientRequest(...) call.
One downside of using this SignalR proxy (at least for WebSockets transport) is that network traffic reachable via Fiddler/Network tab becomes nothing more than the initial negotiate/connect calls to the hub proxy. I have not played around to check out other transport types it might use to see what may/may not show up in Fiddler/Network tab.
NodeJS took a bit of time to wrap my head around what exactly I was intending to accomplish. The end desire boiled down to issuing a request containing data similar to what Transport.js would be sending along via postMessage. I created an Http server listening on port 8889 that would take Http request data, filter it, and issue an Https request to UCWA. When the response comes back for the Https request, write out the status code, headers, body, and respond as if it was the intended Http request. Initially it worked very well for GET requests as there wasn't any complicated body data. For POST (and PUT) requests recalculate the content-length headers based on the inner data (data actually being sent in the request and not the data containing url, type, etc).
Debugging NodeJS was actually a bit interesting from Fiddler/Network tab point of view as the request originates from http://localhost:8889 and the end result is determined by the Url provided in the request body. The request headers are relatively close to the end result with a bit of fixing depending on the request type.
Samples containing GET/POST requests: NodeJS.saz
The many faces of Transport
Currently Transport in the sample libraries makes exclusive use of a cross-domain iframe for communication and it works for most situations. If new transport mechanism were to be added, I could see them being added as part of the Lync Server and started as services (of some sort). Perhaps information would be offered similar to how the iframe is currently offered during AutoDiscovery and based on the option chosen by user/code it could load use the appropriate transport. It would be interesting to take this idea further and see how many supported browsers UCWA could reach by utilizing more transport mechanisms like Socket.IO, etc.