feature idea - Laitos hosted notification service
zutto opened this issue · 14 comments
Yeah.. So. Progressive web applications are a thing on phones nowdays, been for a while. And desktops support same functionality to a certain extent.
So I had this feature idea: Laitos hosted notification service done with javascript using:
- Progressive web application technology on phones to register persistent service workers on phones
- Service workers on desktop
- http(S) as the rest backend
- http(S) upgrade connections - websockets as the backend.
ideas of features of these notifications:
- Send & forget
- send & require confirmation
IE: send notification -> user clicks it -> notification launches another action (laitos http page or something) that includes ticking off the notification, otherwise keep sending it periodically to the user - Other applications should be able to send these notifications using rest/websockets (ie, bash script that can just fire off curl requests 😁)
- Notifications should have importance priority (no vibrating phones or playing notification sounds at night if low priority)
- SIMPLE this needs to be veeeeery simple to the end user and developers sending these notifications
Needed testing:
- websockets vs time.tick-like XHR requests - Mainly for the convenience/speed and the battery consumption on mobile, on desktop websockets are great. We can even let the user decide which one to pick in fact
- other things?
Should this be a stand alone thing or included in laitos? (I'm eventually going to make a standalone service out of this idea, but Laitos would be great place to actually test this out)
If this gets wind under its wings, I wouldn't mind implementing the clientside stuff (JS, progressive app, everything related to the client side), would someone be interested in implementing the laitos side of things?
👍 / 👎?
stuff related to this.
https://developers.google.com/web/progressive-web-apps/
https://developers.google.com/web/fundamentals/primers/service-workers/
https://developers.google.com/web/fundamentals/codelabs/offline/
The objective of laitos is to deliver everything anyone can imagine, i was even thinking about possibility of using morse code somewhere.
For these notifications, how about setting up an HTTP endpoint on laitos to record a toolbox command (e.g. running shell or fetching latest emails), which is called by mobile client to set up; as soon as any command has been set up another designated HTTP endpoint will periodically run the commands and push the results to mobile client.
so:
- http endpoint for client registration
- http endpoint registers new endpoints as clients register
- Inet used if some existing/future toolbox/daemon requires sending notifications
Do we have any way of persistently storing data to disk with laitos (or database!), this would be used for persistent notification sessions, otherwise new session needs to be registered every time laitos restarts 😢
testing how serviceworkers actually work.. running at:
entrypoint: https://jumanetworks.fi/pwatest/index.html
serviceworker: https://jumanetworks.fi/pwatest/service.js
this will be interesting to see what happens during weekend with this.
the service is supposed to throw a notification once every hour.
for debugging: chrome://serviceworker-internals/ (or firefox: about:serviceworkers)
well, first test was unsuccesful.. the service just kills itself after X time.
Testing another thing at the same links, I dont think this will work either.
we'll have to see, we might have to use GCM for this afterall 😢
I still have some tricks up my sleeves tho!
have a relaxing weekend 😄
I spent some time thinking about this feature, and here are several server features to consider:
- In memory, record a number of pre-configured accounts, each account is identified by a string value and becomes associated to a list of transient toolbox commands and a list of pending messages capped to 100 entries.
- Host an HTML form to accept account ID, toolbox command, and arbitrary text entry. Upon submission the new toolbox command goes to commands list, and the arbitrary text goes directly into result messages. A clear button will remove all memorised commands and pending messages.
- The memorised toolbox commands are executed one after another every 10 minutes, each command is constrained to 60 seconds execution time by default.
- Host an HTTP API that responds with all currently pending messages, and then immediately clear those messages.
How does that sound so far?
sounds good 👍
edit update:
serviceworkers are horribly unreliable, as the api's i've been looking at for 2 years.. don't actually work yet.. at all. I thought at this point they would be implemented O.O
I am currently testing a "hack", that should not work but given how promises are implemented.. it might! we'll see in couple of hours.
more progress have been made: f0e7199
Reminder to myself: find a way to inhibit email notifications resulted from these timer commands.
😥 I'm so behind on my side, still haven't figured a way to do this without Google/apple push
no hurry at all
if web sockets are easier for mobile, i'll be writing them on the server side.
Started mocking the web front-end:
https://jumanetworks.fi/pwatest/laitos/
(its progressive web application, so try the 'add-to-homescreen' on your mobile browser!)
And now a question, where this front end should live in laito's folder structure?
I was thinking misc would suit this, but then theres the webapp folder..
That's looking good already.
Till now small pieces of HTML and Javascript code have been embedded directly into go code, if they aren't too long I'd still recommend to embed them into go code, otherwise how about placing them inside daemon/httpd/static?
daemon/httpd/static works for me!
and about embedding them in the go code -
I used material design theme on that, so there would be a lot of embedding to do..
If I were to create the styling and other stuff myself the smallest amount of files would be:
9 icons, manifest.json, pwa.js, and index.html - 12 files in total..
this is what the whole directory structure looks like at the moment, fonts are provided by http://materializecss.com/
$ ls -hR
.:
css index.html js manifest.json poster.png pwa.js
./css:
default.css fonts fonts.css icons material.css
./css/fonts:
MaterialIcons-Regular.eot MaterialIcons-Regular.ijmap MaterialIcons-Regular.svg MaterialIcons-Regular.ttf MaterialIcons-Regular.woff MaterialIcons-Regular.woff2 roboto
./css/fonts/roboto:
Roboto-BlackItalic.ttf Roboto-Bold.ttf RobotoCondensed-Italic.ttf RobotoCondensed-Regular.ttf Roboto-Light.ttf Roboto-Regular.ttf
Roboto-BlackItalic.woff2 Roboto-Bold.woff2 RobotoCondensed-Italic.woff2 RobotoCondensed-Regular.woff2 Roboto-Light.woff2 Roboto-Regular.woff2
Roboto-Black.ttf RobotoCondensed-BoldItalic.ttf RobotoCondensed-LightItalic.ttf Roboto-Italic.ttf Roboto-MediumItalic.ttf Roboto-ThinItalic.ttf
Roboto-Black.woff2 RobotoCondensed-BoldItalic.woff2 RobotoCondensed-LightItalic.woff2 Roboto-Italic.woff2 Roboto-MediumItalic.woff2 Roboto-ThinItalic.woff2
Roboto-BoldItalic.ttf RobotoCondensed-Bold.ttf RobotoCondensed-Light.ttf Roboto-LightItalic.ttf Roboto-Medium.ttf Roboto-Thin.ttf
Roboto-BoldItalic.woff2 RobotoCondensed-Bold.woff2 RobotoCondensed-Light.woff2 Roboto-LightItalic.woff2 Roboto-Medium.woff2 Roboto-Thin.woff2
./css/icons:
128x128.png 144x144.png 152x152.png 192x192.png 384x384.png 48x48.png 512x512.png 72x72.png 96x96.png
./js:
fp.js jquery.js material.js mvc.js ps.js spinner.js
Looking at that ls -R .. there seems to be quite many unused fonts too, I'll clean those up at some point... ~6 font files from "./css/fonts/roboto" are only required I think.
Is this too many files, should I abandon the materializecss and make something that requires less files & drop the fonts? I'm open for suggestions!
Links
- https://material.io/ - google's page for material design
- http://materializecss.com/
Those files look all right, I'll remind myself to note them down in the wiki page about bundling laitos and its data the subsequent deployment.