Repository navigation
Extend socket's life cycle over multiple pages #4
Description
The most common problem of browser-based application or website utilizing full duplex connection is disconnection on page navigation including page refresh unless it is designed to be a single-page application. Now that socket's life cycle is determined by its identifier only, it is possible to extend the life cycle to other page as long as the identifier is shared between pages. Then, the server can send events which the client couldn't receive because of disconnection due to page navigation again when the client reconnects in other page.
The problem is the scope where socket id should be shared. An existing storage like cookie, session storage or local storage shares data between tabs or windows according to the origin policy. They are not adequate because socket in tab1 and socket in tab2 are and should be distinguishable. As far as I know, the only way is to use window.name. Also, it should be considered where two sockets whose uri is same are used in the same page. In summary, we need a proper scope to share socket id and how to add/remove id to/from the scope.
And one more thing - with this option, even though new event has never been called, open event may be called in some page, which is the case where the shared socket id is used and it should be considered in terms of design by contract at first. We should document about it.
Activity
flowersinthesand commentedon Jun 7, 2015
The above scope we discussed is called browsing context according to W3C's HTML5 spec and it seems that
window.nameis the only storage sharing its life cycle with browsing context. Since it is just the name of the window, our use case may be a misuse and not reliable but I couldn't find a better alternative or a unobtrusive solution.For this feature, we need a new option,
name?: string.nameis an identifier of a socket within document and used to identify a specific socket in each document within browsing context. A user should define it explicitly as it can't have default value.Actually,
urimight be suitable as the default value ofnameoption but if two sockets sharing the sameuriexist in the same page oruriis generated programmatically e.g.cettia.open("/cettia?time=" + Date.now()), it won't work.Now we need how to use
window.nameto get/set data indicating that which name corresponds to which socket.flowersinthesand commentedon Jun 8, 2015
Because a way depending on
window.nameitself is obstructive unlike cookie or session storage, there is no way to avoid conflicting with existing libraries usingwindow.name. That's why it doesn't matter even if we monopolizeswindow.name. Of course user should be aware of that.As for how to use
window.name,window.namewill be a JSON representation of an object whose key isnameoption and value is socketid. That's all.