RFC: notification service for LuCI

[aparcar]

Currently LuCI notifies the user if no root user password is set. I imagine multiple other apps and running services have valuable status information to show on login, should we design a more flexible notification setup allowing "third party apps" to add banners?

Right now the password notification is awkwardly handled for each theme in header.htm, involving some Lua code. Instead e.g. a ubus service could return this information and show it dynamically in LuCI.

If it's a framework other services may update a status periodically or on events and add notifications to the ubus daemon, e.g. "New sysupgrade availalbe", "New device connected for the first time", "Adblock list update available", "No internet connection", etc

Using ubus this could even be used by some trivial smartphone app to let users know certain things need attention.

[feckert]

@aparcar I think it's a great idear. It's also on my agenda for a while.

I've had done some thoughts also about that myself a while ago about this topic. My thoughts are:

Ubus Path: luci.message or luci.notification

Ubus Method:

• set The messages that should be send to LuCI are saved with this command in a folder under tmp. One file per message. The content is a json file.
• show Reads out all file messages (file content) from the directory and returns a json array.
• delete Deletes a message from the tmp folder with the array id number.

The question is whether we do add this system wide and not only for the LuCI

[aparcar]

The question is whether we do add this system wide and not only for the LuCI

I'd assume other interfaces could make use of this as well.

Ubus Method:

The methods seem fine, what structure would you use? I'd think of message, title, service, timestamp, more?

[feckert]

The question is whether we do add this system wide and not only for the LuCI

I'd assume other interfaces could make use of this as well.

Then we should put it in the package feed and then we should remove the prefix luci. I would then use system.notification as the ubus path

Ubus Method:

The methods seem fine, what structure would you use? I'd think of message, title, service, timestamp, more?

This should fit. When we display the information in the LuCI, we should also think of the translation.

The implementation is quickest in lua or shell. But since we are working with files here and will be polling the ubus in the LuCI, it is best if we write a small C ubus plugin. We could use the fw3 as a template.

[aparcar]

I'd suggest to use a shell script for now, may add it to openwrt.git at some point if we want it as a default. Are you up for the job?

[stangri]

I've had some experience recently rewriting the advanced-reboot ubus from lua into shell script, depending on how busy you gentlemen are, I can take a crack at it.

My only suggestion is to use some sort of internal IDs (maybe service-timestamp combo) which can be referred to in delete, to prevent accidental deletion of wrong messages.

[aparcar]

@stangri please proceed if @feckert doesn't want to take over. I'd prefer shell until we have something "stable". Unique ID sounds smart.

[feckert]

@stangri If you want you can have a look at it. I would also be willing to review it. I also already have several shell ubus handlers in use.

@aparcar I think that if this is to be included in the openwrt core project, we should write it in C anyway. It's just cleaner.

[stangri]

@feckert Florian, which ubus handlers are these? The only example I've seen was in the wiki, I wouldn't mind checking more code before I have a go at this.

[feckert]

I have written a few myself for my usecase that are not upstream capable, if you want I can send you a few. But I use a shell handler for the ubus in mwan3. It's not perfect but you can use it as a template.

There are also others in the package feed. https://github.com/openwrt/packages/search?q=libexec%2Frpcd%2F

[dibdot]

Wouldn't the (re-)use of MQTT be the better solution - especially if you want to communicate with the outside world (apps etc.)?

[aparcar]

@blogic thoughts?

[feckert]

Wouldn't the (re-)use of MQTT be the better solution - especially if you want to communicate with the outside world (apps etc.)?

@dibdot It sounds interesting, but for now I would start small. if we bring mqtt into the game, then we need other dependencies. Besides, I don't think shell is suitable for that task then.

As an alternative, we could introduce a /etc/hotplug.d/notification, where scripts are stored that do something with the message. You could then trigger your mqtt handling. On every add of a notification via ubus.

[feckert]

@stangri Sorry I dragged this on myself now. But I have a urgend use case for this case and wanted to move on as quickly as possible. Besides, I have some time right now.