Hi.
Have you considered making the UI that way so it loads the files from a CDN (a server on the Internet) instead of the router itself?
This would save some space and potentially allow 4MB Flash routers to use the GUI.
I find this especially suitable for the upcoming LuCI2 web UI.
Any thoughts on this.
Can you clarify, how exactly would this make the router use more RAM?
As far as I know it wouldn't affect it at all, the page is running on the client side.
How would you accomplish that? Are you suggesting that "LuCI 2.5" is effectively a client-side app?
If so, then you could write a client-side app that accesses either existing API or command-line through SSH. There was a recent thread on that idea for Windows machines, as I recall.
This is how OpenWrt works already, more LuCI modules can be added as desired.
Cache where?
The browser?
How, if the user has no Internet?
And if there's no Internet, you've saved the user from needing to program a router for Internet. This is a chicken-and-the-egg problem/solution. Also, how do you download the software if there's an outage?
In your description, you have to perform a download, then process that data. Currently on OpenWrt, you just process the page.
It does sound like you wish to write a client-side app.
As I'm familiar with client-side configuration tools for several business oriented commercial router firmwares, pbx systems and switches, I can only strongly recommend against this madness. Infrastructure devices tend to stay around for a long time, even beyond their EOL/ EOS dates - and it's very, very inconvenient having to keep a VM with e.g. Windows XP before SP2 and no security updates around, just to run the configuration program for your ISDN pbx.
The same goes for relying too much on fancy web frameworks of the day, which age very badly (the ie6 dilemma). A router firmware doesn't need to look pretty, it needs to work - and be compatible with ~10 year old browsers, just as well as new browsers 10 years into the future.
And yes, obviously as mentioned before, you definitely can't rely on external services for anything, APIs break, servers go away - and you need administration access to your router most, when the internet isn't working.
How would this work in a scenario where interaction is required before the Internet comes online - common examples in the community follow:
PPP WAN connection needs credentials
VLAN ID must be added to the WAN port
static IP must be assigned (i.e. no DHCP)
specific WAN MAC address must be used on Interface
wireless WAN (WWAN) is needed instead
the WAN/WWAN has some local captive portal requiring interaction before Internet is activated
the upstream network administrator is blocking traffic to the CDN - for various reasons, this is not uncommon or far-fetched in some countries and networks
any config other than the OpenWrt-default DHCPed WAN
I agree.
...I guess, I'm just having difficulty understanding any practical situation when such a user would actually need it - the problem is, every scenario I imagine, is at a time the Internet is down.
terrible terrible idea, adding an internet dependency to use the UI, as well as internet latency.
also you can get very cheap devices that have enough ram and flash to handle luci. My old NT16 handles it and I brought a used archer C7 which handles it just fine.