Hi, I think I just made a complete ass of myself and really shows my lack of knowledge regarding javascript. Since the iframe can access the parents objects, as long as the parent initiates the connection and "owns" the connected client, the iframe can get that client through window.parent, completely obliterating the suggestion I gave :) Ahwell, at least I got some more knowledge about javascript :)
Thanks and "sorry"! 2017-01-05 0:46 GMT+01:00 Martin Hejnfelt <m...@newtec.dk>: > Hi Jens, > > Thank you for taking time for this. > > Den 5. jan. 2017 00.05 skrev "Jens Geyer" <jensge...@hotmail.com>: > > Martin Hejnfelt wrote: > > > 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. > > Not the object, but you can save some identifier (e.g. a SessionID) into a > cookie and/or pass it back and forth through each page reload, whatever > makes more sense. That ID is then used to reinitialize the next page. > > > Yes, this is what I've usually done when making similar projects from > scratch, storing a session ID, which then acts as the token used, and > authorized by the server. The "problem" with that approach is that the > server must then have specific knowledge about this, thus it needs new > code, some that works for this approach when dealing with a JS client, and > another when dealing with a Java client (or any other raw socket client). > > The server would also need to "save" the clients' state somehow, like > saving the handler instance, to be able to recreate the previous > connections' state. Again this can be avoided with persistent connections. > > If the connection is persistent, the server/service handler doesn't need > to differentiate between the different client types. Of course there would > be two different servers one for raw sockets and one for websockets, but > the handler codebase could be the same. > > > 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. > > So in other words we need the IFRAME only to preserve some information > about the connection, right? And if you store that into e.g. a cookie, > there is no need for the IFRAME anymore? > > > In my head, the iframes content is what is actually seen by the user. It > contains the webpages that contains the code which needs the thrift client > to interact with the server. > > Again if you store a cookie, the server needs knowledge about it. That > implies a parallel system serverside, more code, more maintenance. > > Second, you wrote plural “clients”. Does that read (a) “Only one IFRAME > and one client at a time” or is it really (b) “more than one IFRAME / > client in parallel”? > > > Each page will, when loaded, create a client instance. Technically only > one client will exist at a time, at least if only one iframe is present at > all times, but the underlying websocket, in the top window, will be > connected constantly. > > Have fun, > JensG > > > I tried actually doing some code and it seems to work just great. I made > two new JavaScript transports, a TTopWindowTransport that will wrap the > TWebSocketTransport in the top window and a TWindowTransport that is > instantiated by each webpage loaded in an iframe. I can then keep a > persistent connection, between pages, to a C++ server. > > In my head this mimicks how Thrift works when dealing with raw socket > languages like C++, Java even PHP. In the past, we did not have these raw > mechanics for web, and thus relied on XHR or the likes, but with the rise > of websockets, we can now have webapps that work with (almost) the same > mechanics as "traditional" applications. > > Best regards, > Martin Hejnfelt > -- Mvh. / Best regards Martin Hejnfelt Development Engineer Newtec A/S Staermosegaardsvej 18 5230 Odense M Denmark Tlf.:+45 66158444 Dir.:+45 63154881
