The notifications service would allow for push-type (polled frequently enough to simulate push) notifications which in the future may be a full push service. So far the only notification I have defined is location push (click a position on a map online and click send-to-car)
notifications getNotifications(string sessionKey)
string getLocations(string sessionKey)
Returns a list of addresses or Lat/Long pairs
yup... the goal is to minimize bandwidth usage unless theres actually data to be transferred. On second thought it should probably be:
notifications getNotifications(string sessionKey, DateTime lastCheck)
that way even if a connection drops theres no lost notifications.
Hey... I never thought of this idea.
Ideally, maybe this should be a core/required webservice for the other webservices to function? When a download or update for the car is ready/changed, it sends data first through this service instead of each client plugin/app polling individually?
We need to expand upon this more to specify which service is updated and ready to push info to the car. This service should notify for ALL push type services to the car such as downloads, updates, and etc...
Any ideas on how this could work for all services?
I think that kinda defeats the purpose..... The only functions that should be part of the "notifications service" are functions which require push type notifications. The other services don't have data thats changes are urgent enough to warrant immediate notifications.
Here is how my idea works. Instead of having dozens of plugins/apps polling for new data, which wastes bandwidth and cpu cycles, you have a single app that polls for new data and lets the client plugin/app know to download new data.
Old/Current Method for Polling and Downloading Updates - every app/webservice polls on their own for updates and new info
New Method - all webservices will announce updates through the notification webservice and apps will only download updates once the notification app/plugin tells them too
This will save valuable BW and cpu cycles. Now do you get the full scope of my idea?
EDIT: After posting this, I think I kinda see your point. Not many webservices actually have changing data come back to the client. Even with website based data changing, the client is usually off. Anyways, here are some of the services which might need this:
- Traffic updates and accidents
- Weather updates (floods, tornadoes, etc...)
- Current news and headlines
- Real time hardware control? (like making the FB do things remotely from a website)
Yeah... I think we should avoid using the notification service habitually for everything that needs a response. I'm unclear at this point how the client will react to a notification or how the client will know exactly what the notification is for and what type of data it carries. I'll roll over in my head this some more...
Former author of LinuxICE, nghost, nobdy.
Current author of Automotive Message Broker (AMB).
Works on Tizen IVI. Does not represent anyone or anything but himself.
As far as a clients reaction, I think thats pretty much defined based on the data.
why not follow in apple footsteps? Application speaks to notification service, notification service has a single connection to the client. So there is no constant checking, when say there is a severe weather alert, that message speaks to the notification service which sends a message to the client where you see it.
Any application could use the service and not slow down the push, or use extra BW.
This isn't a true push service....something like that requires a custom web server which none of us have the time to put together. This service will be similar in that instant notifications are instant where as slowly changing data will be checked often enough to be current but rarely enough to not use unnecessary bandwidth.