Hi, TL;DR in the bottom.
I've been using Thrift for many years now, as a RPC between a server and a frontend, where the server is written in C++ and the frontend in Java/Swing. The system works by having two services, one for the "controlling" part, meaning the commands coming to the server from the frontend, and a "talkback" service for the server to be able to push notifications to the client. To avoid using polling, and to avoid having a "direct" line back to the client from the server (so the client can be behind NAT), the server itself has two servers, one for the control part, and then another one, where, when a connection has been established (meaning the return from accept()), a client instance is created, with this connected socket, which is then fully operational. On the other end, the client then starts its own service instance (functioning mostly like a TSimpleServer) with the connected socket. Both connections are persistent throughout a clients "lifespan". Now each client connection instance carries its own access rights token so to say, a token that tells what that client is allowed to change on the server. That means that two clients not necessarily have the same access rights, and when/if they disconnect, their rights are reset upon reconnection, as the new instance is "bare". I now want to switch away from Java/Swing onto a web frontend, written in javascript utilizing HTML5 features, in my world what is called a "webapp". This poses some issues, if I want to keep compatibility for the old frontend. The javascript library contains either a XHR or Websocket transport as it is now. XHR would not work for me, without changing the IDL (eg. each method has a token built in) or creating some additional authorization mechanisms (which I am not sure would work anyway). The Websocket transport is really what I need, and I've created the necessary "TWebSocket" transport for this to work with C++, however then comes the issue, that each webpage, when "browsing" through the app, will have no knowledge about the previous connection, and as far as I know, there is no way of "saving" a connection object like this in the browser for persistance. And now comes why I wrote to the dev list: TL;DR To keep a persistent thrift websocket connection on a javascript based "webapp", where multiple pages should share the same client instance, I propose to create a "TPageTransport" or something like that, that utilizes javascripts features onmessage and postMessage, so a persistent hidden top window/frame will have the "real" connected client, while the pages (inside an 100% width/height iframe) initializes "clients" with the TPageTransport which then through these onmessage/postMessage methods gets data to and from the "real" client. Does this make sense? I am asking because I am no skilled javascript developer, so I need to gain new knowledge to try all this, but if I am completely off, or something already exists, I'd like to spend the time elsewhere :) Any comments, requests for elaboration even flames are welcome :) Best regards, Martin Hejnfelt
