At first I will be only focusing on what will be new features for LUCI that I am missing at the moment.
Please do not expect results soon though. I am terribly slow.
Also I need to get accustomed to the coding guidelines being applied here.
What I do have is some experience on the front end so what ever I make should hopefully be worth merging into the master branch.
At first I am thinking to make the Lucy System log more interactive. With tail and filters.
Where can I get more information on how to make a client side call that will give syslog data?
Currently Luci just appears to call logread and dmesg in order to obtain the logs. See /usr/lib/lua/luci/sys.lua One can get direct output from the kernel via /dev/kmsg and I believe logread uses ubus to read the logs, see https://openwrt.org/docs/techref/ubus
yes thank you. I did not mean to ask again on how to get syslog data. I meant rather than reinventing the wheel I will take a look at the already existing code that does it.
But I did mean to ask if an api with a schema like api/log/system/? and a query string is something the community might benefit from.
I can make it return XML or JSON or both based on a QS param.
To be honest, there's little point trying to get a consensus on whether a feature you want to add might be useful or not. If you think it'd be useful and you're going to put in the work to implement it then do the work and submit a pull request to the appropriate github repo. If it does turn out to be an improvement over what already exists then it may get merged, but keep in mind there's no certainties.
Hi Thanks for wanting to get your hands dirty in luci's code. Pleas don't be put off by the brusk manna some posts can be ritten in. People on this forum are really nice. It's just people want to get there point across as succinctly as they can. They are all volunteers with dayjobs and stuff like that. People have bin really helpfull to me when I have asked for a11y changes in luci.
As you are new I think you were looking for some encouragement.
I am not a dev I am just a blind dude that likes to tinker around with flashing routers.
I cant help out with code, but what I can tell you is coding for OpenWrt/LUCI is not like coding for a website.
When building luci apps and making changes to luci size is everything. Some of the routers have just 8 mb of flash so building anything that has to use a big lib or framework is a no no.
Where most people start is digging around on github and getting to understand just how luci works. The way luci shows the logs is just by calling logread and then put ing the plane text on the screen.
If you would like to add anything to this it would have to be small.
You will not have to worry so mutch about this if you made a luci addon {package} You could call it luci-app-logreadplus.
Log-read-plus.
I hope this helps.
Good luck mate.
If any of this is rong other people pleas chime in.
We need to get people intrested in contributeing to OpenWrt!
Come to think of it as a screen reader user it would be good to beable to hide the date and time when reading the log becase I have to wate ages for my screenreeder to read out the hole lot befor it gets to the good bits.
EG I will post what my screen reader reads from my log.
{Sun May 8 10:04:55 2022 daemon.info hostapd: wlan0: STA 5e:a0:f6:37:3a:43 IEEE 802.11: associated (aid 4)
Sun May 8 10:04:56 2022 daemon.notice hostapd: wlan0: AP-STA-CONNECTED 5e:a0:f6:37:3a:43
Sun May 8 10:04:56 2022 daemon.info hostapd: wlan0: STA 5e:a0:f6:37:3a:43 WPA: pairwise key handshake completed (RSN)
}
So my screenreader has to read all of that out to me. Now heres what It would read as if I could hide the time and date
{daemon.info hostapd: wlan0: STA 5e:a0:f6:37:3a:43 IEEE 802.11: associated (aid 4)
daemon.info hostapd: wlan0: STA 5e:a0:f6:37:3a:43 WPA: pairwise key handshake completed (RSN)
}
To get how that would be for me you have to read out loud every char in the blocks of text.
Based on the ubus suggestion made earlier on this thread I am now considering to making firefox add on(s).
Tiny javascript code that basically does what needs to be done.
Easy for people to inspect as to keep it on the up and up and easy to install/deinstall.
So no changes needed to the code base.
And yes a little encouragement, like the most resent posts, is what motivates. thank you!
But it seems there already is an API. the exact ubus as suggested earlier.
I never realized until recently as I was not looking in the correct places.
Take a look at the current DNS leases (EDIT, I meant DHCP lease) overview. And how it polls.
Sure not all the new standards in API communication are employed. But I have given my self the freedom with having over more than 28 years of web development experience I will call this an API.
Because is it an interface? yes
to what? application / program
first thing on my mind would be to have ubus be more intuitively approachable.
More along the lines of what the current luci path displays, ubus is supposed to give all the relevant data regarding that.