Extend socket's life cycle over multiple pages #4

Closed
flowersinthesand opened this Issue Jun 3, 2015 · 2 comments

Comments

Projects
None yet
1 participant
@flowersinthesand
Member

flowersinthesand commented Jun 3, 2015

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.

@flowersinthesand flowersinthesand added this to the 1.0.0-Alpha2 milestone Jun 3, 2015

@flowersinthesand

This comment has been minimized.

Show comment
Hide comment
@flowersinthesand

flowersinthesand Jun 7, 2015

Member

The above scope we discussed is called browsing context according to W3C's HTML5 spec and it seems that window.name is 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. name is 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.

// A socket whose name is 'main' after page navigation will continue this socket's life cycle
cettia.open("/cettia", {name: "main"});

Actually, uri might be suitable as the default value of name option but if two sockets sharing the same uri exist in the same page or uri is generated programmatically e.g. cettia.open("/cettia?time=" + Date.now()), it won't work.

Now we need how to use window.name to get/set data indicating that which name corresponds to which socket.

Member

flowersinthesand commented Jun 7, 2015

The above scope we discussed is called browsing context according to W3C's HTML5 spec and it seems that window.name is 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. name is 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.

// A socket whose name is 'main' after page navigation will continue this socket's life cycle
cettia.open("/cettia", {name: "main"});

Actually, uri might be suitable as the default value of name option but if two sockets sharing the same uri exist in the same page or uri is generated programmatically e.g. cettia.open("/cettia?time=" + Date.now()), it won't work.

Now we need how to use window.name to get/set data indicating that which name corresponds to which socket.

@flowersinthesand

This comment has been minimized.

Show comment
Hide comment
@flowersinthesand

flowersinthesand Jun 8, 2015

Member

Because a way depending on window.name itself is obstructive unlike cookie or session storage, there is no way to avoid conflicting with existing libraries using window.name. That's why it doesn't matter even if we monopolizes window.name. Of course user should be aware of that.

As for how to use window.name, window.name will be a JSON representation of an object whose key is name option and value is socket id. That's all.

Member

flowersinthesand commented Jun 8, 2015

Because a way depending on window.name itself is obstructive unlike cookie or session storage, there is no way to avoid conflicting with existing libraries using window.name. That's why it doesn't matter even if we monopolizes window.name. Of course user should be aware of that.

As for how to use window.name, window.name will be a JSON representation of an object whose key is name option and value is socket id. That's all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment