There are cases in which there is no possibility to handle asinchonous event from server.
Consider for example you developed a simple websocket server and you want notify the user with a message but user is surfing in another page or in another domain and service worker is down. Service is registered so it is accepted by user and user can remove it when he want. Un another case if client receive a event and it might executing a simple job reading in the local file system (it can read/write just in the domain isolated area so it is secure) addiing info to a javascript agent.
Service worker cant attach a listener to a external datasource for triggering the service worker to wake up and to process a event. For my opinion is a very important thing because with html5 we have websocket, http2 asinc,… but no way to handle in client side this powerfull feature except when user is a specific page, but for definiton if a event is asincronous you can t foresee if the event is arriving when user is in a specific page/domain.
this.registerExternalDatasource(obj) visible just inside a service worker.
obj can be one of these possibilities
or is a websocket object
ss is EventSource object
htm3 datasource
…
In this way the browser dont close the connection until the browser process is active.
service is idle normally so it dont use cpu Just when a event is received browser wake up the service for permitting to process the event. Then it go back in the iddle/terminated status as it was before.
developer uses the normal listener for the specific datasource for handling the event inside the service. So for the user pratically no change. But he has the possibility to make many many things before not possible.
It will always use CPU as long as it is running. It just won’t use as much if it is “idle”.
when a event is received browser wake up the service for permitting to process the event
If the process is idle, it can’t listen for the event to wake it up.
possibility to make many many things before not possible
Such as?
Some things are able to sleep and periodically wake up to check for changes, but this is only possible because the same event is broadcast many times over. This may be the type of thing you are looking for, but it’s not feasible unless you want to broadcast the same message over and over.
about idle status …yes i know but i know it is a important poiint for browser developers so it is importnat to confirm nothing will change about it.
I tested the behaviour in the browser. Simply it not present. No management.
Such as? i described on the top important possibilities… and the contradictions present in asynchnous api
The contradiction maybe more evident is using websocket … every time i change page the connection is closed and again open when i reload a page.It is not a socket but a tweet . Sureliy is not a best practice and not a best design.
Anyway bihind this problem there are many future challenges and aspects can open to new possibilties for the web.
I dont tell about it because for now there are to solve the basic practical cases.
User A send a message to Server. Server send to B a message, but user B is surfing in another domain so service worker is idle so process is active but also if was active probably the connection was already closed for 2 reasons
the are no specifc w3c in this case so every browser has different behaviour or no management .
the connection si closed the first time the user pass to surfing also just a minute to another domain.
I’m still not clear on what you’re proposing. Are you proposing something new, or just to have websockets persist between page loads? If it’s the latter, that can be solved by having page loads done with AJAX, something many sites already do.
I wrote the api proposed and its behaviour. I wrote the critical problems in the actual api the the contradiction in the actual design.
Ajax is not websocket and websocket is not event source and event source is not html3. Every tecnology is designed for s specifc scope.
So to propose to solve a problem with another tecnology designed for other is just a way for hiding a problem not for solving it
.Anyway also using ajax you cant functionally to solve the problem.
Ajax is designed for receving a async answer but not async question.
If the event is decided by server and not by client how to do with ajax? I m telling about the possibility to give the possibility to the browser to talk with the server (not only to command the server) when the user is surfing in the web (not in the page because if the event is from server i dont know the moment in which it is generated so the time line must be the entire life of a browser instance).
A “service” is defined so if it works emulating a service in background , but so it is not. In addition the lifecycle of a web socket is break when you pass from a page to another and again in it for what reason to create multiple connections if the user is always in a browser and in the same process instance?
Web socket is designed for overcoming the unidirectional channal and the overhead in the communication using ajax but pratically now the overahead is moved in the server in the moment you create a new connection for every page reload. It has no sense also if you dont think about the extension described here.
It is necessary to align the tecnology present in the browser with the actual possibilities offered using hml5 and the html protocol extention.
Maintaining a persistent WebSocket connection would translate to poor battery life. And as a user, I would prefer that background web apps respect my battery life and not waste it.
I feel like the better approach would be to register for push notifications via your Service Worker, and send a push notification when you want to notify the user of something. When they follow the notification back to your web app, you can re-connect your WebSocket connection if it makes sense for your use case.
There is another use case: where you want to notify your app without notifying the user. However, I feel this can be pretty user-hostile, and browser vendors would not want to provide APIs that allow developers to be sneaky. As a browser user, I expect browser vendors to try to protect me from sneaky web apps.
Exactly - service workers support push notifications. Push notifications supersede web sockets and event sources in service workers. They wake the service worker.
(HTTP/2 Push is not entirely related to asynchronicity, really, it is a mechanism to send resources the page needs in advance to the client. The client usually has a short timeout for keeping those resources, so if the web page does not request them at some close point, they are gone)
You might want to take a look at those slightly similar proposals, though -
sincerelly i dont uderstand why web socket suck battery. ping pong message is optional in the specifications.
if the connection is not exchanging messages until the real event … for what reason it consume energy? It is a interrupt activing the processor so there is no additional cost. The cost is using the job like cron … because the processor execute code but you are not sure to have things to process, For my opinion is equal to push notification.
Push notification can send just short messages. Websocket can make more than it
It is a simple job similar to cron service =>
1 ) many loop occurs making anything until a real event happens so eventually it consume battery more that a os interrupt in a socket.
2) in a job is the client deciding what a event happens not the server => monodirectional channel from client to server not opposite. The revolution is the opposite direction.
There is no new revolution here - push notifications are already supported and are already monodirectional from the server to the client. You can do other things except showing a notification, you have a few seconds there or something and you can call web APIs and such.
Having a bi-directional communication does consume power and it is against one of the general concepts of the web (when not using a website, it does not affect your system).
In non-mobile platforms, you can use an extension with a background page. Since Chrome extensions are the de-facto way of creating extensions nowadays, even this code can be cross browser.
“push notifications are already supported and are already monodirectional from the server to the client.”. Yes why use another technology when websocket are bidirectional permitting client to give also a answer to server ?
It seams really just a trick by google for a business not a real need. The revolution is not to create tweet from client to server or opposite but create a talk. It is very different. It is very nice to hear that bidrectional consume energy if it happens when there is a real event actived by a interrupt but a job processing when no event happens doesnt consume energy . It is a nice story telling
You might be able to create a web socket connection from the service worker while responding to a push notification, I do not know, but you will have a few seconds of communication for the reason I stated above - not using a website should not affect the system.
To summarize, I think your proposal goes against the philosophy of the web platform. But others may have a different perspective.
you didnt understant the proposal if you tell it.
Read again above.
The connection is already actived. The connection is actived when the browser is started and cached internally. When a message is arriving the service is wake up.
The websoket is a designed for be a socket not a packet.
A interrupt awake up the service so no additional energy used as in job (actual solution)
it is bidirectional (actual solution is monodirectional in push api)
it is real time (actual is not really defined this feature in push api)
it can contains long messages (not it is not possible in push api)
it solve also overhead in using websocket when you reload a page. It is a real bug in the websocket usage
You can reject the proposal but i m sure the web will come back to require it… in future, because it is obvius the big missing hole
If you do not interact with a web socket, it can time out and close itself. This is problematic because it means that some process must send ping/pong messages every now and again, which means some process must run in the background and send packets to N (websites that use this feature) web sockets just in order to keep them alive. This activates the internet connection, wakes the device up and uses power and data.
You are wrong. There is no timeout. The timeout can be defined just if the server set it. It is in websocket specification. it is optional. Dont you know it? The ping pong is not used already now in many server http
I read some StackOverflow answer that warned about the timeout, actually. I do not know the effects of an open socket in this situation (no need to explain it to me, though).
Yes timeout is defined in websocket server. If you set 0 it is indefinite. browsers works also without pingpong. Because it the server deciding if sending ping or not.
Obviously the requirements using service worker is timeout set 0 because browser doent answer to ping. It is obvious.If a server is wrongly set it is a “problem” (it close the connection) in the server not in the client.
if the server knows that connection is used for service worker timeout is set to 0. just it
In addition to all problem above, i found now another big problem in the actual design.
Define A set of subscribed devices. Define B the set of the actived devices subscribed.
B is a subset of A and B << A (B is statistically a lot lesser than A).
Define E the endpoint permitting to push a message from the server. Define S the server sending a generic message.
The actual api dont give any information when a device is active to the server S pushing messages. E might send to S a information when a device is not active (or better when the user is down).The conseguence is the server S
send always message to E even if no user is listening for that message.
Pratically the server S send many messages as A , not B.
This overloads the server, consumes useless bandwidth , energy. A montaign of all for nothing.
so it is importnat to confirm nothing will change about it.
I tested the behaviour in the browser. Simply it not present. No management.