Re: [OpenWrt-Devel] [ANN] LuCI - Lua Configuration Interface
Hi, I think this is a good idea. Though, it isn't the 'break-up' I imagined when I first started reading your message. I just assumed the LuCI webif was minimal with the option of adding tabs -- much like the original webif. I suppose the questions I still have about the LuCI webif project are: 1) will it try to only configure UCI files, or will it generally be creating application configuration files? 2) will it become the driving force in defining the UCI variables and their meanings? In my mind, there are several distinct elements: - creating application configuration files for the packages needed to implement 'features'. - defining and the logic of 'feature settings' (for lack of a better term) expressed in UCI, for example LAN DHCP Network being written into UCI config/dnsmasq or config/chilli based on the option Hotspot Enabled. - and the web interface to configure it. The first element is largely the task of shell scripts for core settings, and the rest is LuCI. The more you keep the elements separate, the easier it is to switch out the pieces, which I believe is a key element in getting a broader contributor community over those interested in this specific web presentation. I would even add another element above the webif for: - configuration and status web services (API) to further decouple the features (gathering status, setting UCI) from the presentation layer. Cheers, David On Sat, 2008-07-19 at 20:13 +0200, Steven Barth wrote: Hello Everyone, much work has been done this week and thanks to your feedback and opinions we are happy to inform you about the latest project updates. After the recent discussions about user-friendly vs. full-featured interfaces we decided to split up LuCI into two parts LuCI Administration and LuCI Essentials. Administration is the usual full-featured power-user interface while Essentials serves the non-power-user's needs by just providing the most important configuration settings in a simplified user-friendly way. Essentials contains configuration and status pages for basic Network, Wifi and System settings and can be extended with modules for Portforwarding, QoS, DDNS, UPNP, Time-Synchronization Everything of course with theme and translation support. You will find some screenshots of Essentials here: http://luci.freifunk-halle.net/WebUI/Screenshots/Essentials Build instructions - as usual - can be found here: http://luci.freifunk-halle.net/Installation LuCI Essentials (as well as LuCI Administration and the additional modules) can be found in your build configuration under Administration - LuCI - Webinterface Components after adding the LuCI OpenWRT feed to your buildroot. Greetings Cyrus ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [ANN] LuCI - Lua Configuration Interface
Hello Everyone, much work has been done this week and thanks to your feedback and opinions we are happy to inform you about the latest project updates. After the recent discussions about user-friendly vs. full-featured interfaces we decided to split up LuCI into two parts LuCI Administration and LuCI Essentials. Administration is the usual full-featured power-user interface while Essentials serves the non-power-user's needs by just providing the most important configuration settings in a simplified user-friendly way. Essentials contains configuration and status pages for basic Network, Wifi and System settings and can be extended with modules for Portforwarding, QoS, DDNS, UPNP, Time-Synchronization Everything of course with theme and translation support. You will find some screenshots of Essentials here: http://luci.freifunk-halle.net/WebUI/Screenshots/Essentials Build instructions - as usual - can be found here: http://luci.freifunk-halle.net/Installation LuCI Essentials (as well as LuCI Administration and the additional modules) can be found in your build configuration under Administration - LuCI - Webinterface Components after adding the LuCI OpenWRT feed to your buildroot. Greetings Cyrus ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [ANN] LuCI - Lua Configuration Interface
Hello wlanmac, at first thank you for your feedback. will it be difficult to remove overall or will the LuCI code be mixed up with non-GUI scripts? It's just a separate set of packages: not more, not less. As for LuCI, I would like to know more about why Lua and hence LuCI? You say It's not that difficult. - yet it does require learning a new language for most people and I don't see the huge benefit over using traditional shell scripts. That point would only matter if you do a shell-only interface like x-wrt did. But if you are using the Gargoyle approach - that is not bad but simply a different approach - you have to mess up with Shell and learn JavaScript or in your case *yourFrontendLanguage*. And you don't see any benefits of a programming language natively supporting floating point arithmetic, tables (hashmaps, arrays), a module-system, metatables (allowing prototyping, ...), file pointers, regular expressions, precompiled bytecode, ... over shell? It might be faster, but is that at the cost of complexity? You always have the complexity of separating view and programming logic as well as including i18n-support and multiple themes for example. It might be simple (once you know it) You should have a closer look at the LuCI documentation, the howtos and the source code. For the very basic stuff like writing a webinterface page for your application that already supports the UCI, it's just following a howto copying some code over and adapting it. And also for the more advanced tasks learning Lua is not that problem if you do know basic programming techniques and you should if you plan to develop an application. Besides that switching over from shell to Lua is easy if you keep in mind the sed/awk escapades in shell seen in other webifs. To the point the that JavaScript is probably more popular than Lua: If you know JavaScript it should be easy for you to learn Lua in a few days. but enough to attract new developers? oh, we will see. btw: It's not that difficult. vs. all using the same VERY simple XML GUI logic You see the point? ;-) I also agree with Eric, that the 'kitchen sink' doesn't really make for a good router interface. It might be useful for more advanced users - who know and understand all the options of a program, but not for your target audience, imho. I should have noted that before somewhere, but we are preparing a second simplified module that will not use the 'kitchen sink' but a smarter approach offering the most important features in a simplified form for the beginner (a bit like Gargoyle does). That would give us the ability to support both beginners and power users by letting the user decide which module of webif they are using. As it is not a good idea to only have a non-full-featured interface in the application. That's like domineering over the user. At least for the current state of the docs administrating OpenWRT via the shell and uci-cli is a bit painful. That's why we have started building the full-featured webif. And, as a application developer, I'm less interested in spending time making a 'smart' GUI for my application if it is limited to LuCI -- I would rather spend my time on something a bit more portable as my application also isn't limited to OpenWrt. I think that's not the point here: LuCI uses UCI (Universal Configuration Interface) that is an OpenWRT-only thing so we do not mess with the application itself but only throughout the standardized UC interface. And to not forget the application developer interests: Such an interface must link together different programs. Like when you want to use a WPA-encrypted DHCP-offering WLAN as your WAN interface. So you need the wpa-application, the dhcp-client, the wifi configuration subsystem and the network configuration subsystem of your os and probably also the firewall and for that all there is no OS (or even linux-distribution) independent solution. So you end up writing code for each linux distribution to be not limited to OpenWRT. Maybe not for all but I think for the greater part of the applications. And doing everything by hand with ip, iptables commands etc. would surely break the distribution's configuration system if you try to use an independent approach. So for me as an application developer it would be both not interesting to write an interface using LuCI or - if I understood your plans right - using your approach. That is at least some feedback. That notwithstanding, good work and great project! Thank you. I like the different approaches of you and Gargoyle that's how Open Source should work. And I also would be interested in seeing your sourcecode if you plan to make it public somewhere. greetings Cyrus ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [ANN] LuCI - Lua Configuration Interface
Yeah, sounds like many scripting languages... except shell ;-) Agreed, there is always some distribution specific glue needed. I'm leaning toward a 'meta configuration' (in XML) which can be edited, verified, and translated into distro specific configurations. Ah I see you added another abstraction layer in form of XML and have a kind of meta-format. Sounds interesting. We use a more UCI-based approach using an abstraction layer called CBI. The interface-designer just specifies a kind of model in Lua describing the scheme of the UCI file. This models conatins relations between configuration section and values like: there is a section, containing an on/off switch enabled and an optional text-value dummy. There is another text-value dummy2 but it will only be used when dummy is set. See this example: http://luci.freifunk-halle.net/WebUI/Documentation/ModulesHowTo#CBImodels The CBI then uses an appropriate renderer (at the moment HTML-templates) to create the output and validate the user input. As such, it is too bad it (the advanced logic part) can't be used outside of the GUI framework... or can it? You could for example use some Lua-ncurses bindings and write a CLI renderer for the CBI then you could completely reuse your models and i18n-files for a different thing and create a console based adminsitration app out of it but as long as you don't write an UCI - non-openwrt-configuration scheme translator it stays OpenWRT specific. And of course you cannot use any non-CBI-models like your HTML-templates that you may have written for something like a statuspage that shows your memory consumption. But regarding this you will use a different approach for such a thing when you use ncurses. But at least you could reuse the LuCI system library function that fetches the memory consumption information into a usable data structure. I'm not suggesting one approach is better than others. Developers tend to work with that they know (or otherwise have an interest in). And, one thing is for sure, with a user interface, no one solution is for everybody -- particularly so in OpenWrt devices, I'd say. That's right. Your approach also has its advantages and that's good. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [ANN] LuCI - Lua Configuration Interface
On Tue, Jul 15, 2008 at 12:38:24PM +0200, wlanmac wrote: But if you are using the Gargoyle approach - that is not bad but simply a different approach - you have to mess up with Shell and learn JavaScript or in your case *yourFrontendLanguage*. True. But, I'd argue that JavaScript and XML tools are useful technologies for anyone to know. I thought Gargoyle was interesting, although my money is on serving the config files as xml, using xslt to do the presentation layer parsing the xml-ified config files to html+css and then using ajax calls to pass back the data. As a result, there would be a single url per /etc/config file and only a sparse api for passing uci variables. So you need the wpa-application, the dhcp-client, the wifi configuration subsystem and the network configuration subsystem of your os and probably also the firewall and for that all there is no OS (or even linux-distribution) independent solution. So you end up writing code for each linux distribution to be not limited to OpenWRT. Maybe not for all but I think for the greater part of the applications. Agreed, there is always some distribution specific glue needed. I'm leaning toward a 'meta configuration' (in XML) which can be edited, verified, and translated into distro specific configurations. And to think uci was invented to simplify things ... *sigh* ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [ANN] LuCI - Lua Configuration Interface
Sorry, but in some respects I look at all these web interfaces and just cringe; the webif was never meant to be a lifelong ambition, it should only be a very thin layer between uci and the browser. All of the schema and validation, as well as the i18n should actually be handled on the uci side of things and should not be duplicated by every presentation layer loaded ontop of uci. In other words, I should be able to point at any variable and get uci to tell me where it fits in the overall schema, what the possible values are and what the i18n description of the variable is, in whatever language packs I have installed. Not exactly the path being taken... unless LuCI becomes the back-end for UCI itself -- which was sort of my original question/concern. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [ANN] LuCI - Lua Configuration Interface
Hi, Sounds good, but perhaps not for everyone. This will be integrated into the main firmware or will it always be a package? I'm not concerned about it being installed per default in the OpenWrt-built firmware, but will it be difficult to remove overall or will the LuCI code be mixed up with non-GUI scripts? Like Eric with Gargoyle, I also already have a GUI for kamikaze. I will not bore you with defaults, other than to say it completely separates UI from data by using a completely static web application (which can be put on the router or into a desktop app!) while only requiring very minimal 'data services' scripts on the router. It is also not specific to OpenWrt, is very suitable for a desktop GUI or built into a back-end web application, all using the same VERY simple XML GUI logic. As for LuCI, I would like to know more about why Lua and hence LuCI? You say It's not that difficult. - yet it does require learning a new language for most people and I don't see the huge benefit over using traditional shell scripts. It might be faster, but is that at the cost of complexity? It might be simple (once you know it), but enough to attract new developers? I also agree with Eric, that the 'kitchen sink' doesn't really make for a good router interface. It might be useful for more advanced users - who know and understand all the options of a program, but not for your target audience, imho. And, as a application developer, I'm less interested in spending time making a 'smart' GUI for my application if it is limited to LuCI -- I would rather spend my time on something a bit more portable as my application also isn't limited to OpenWrt. That is at least some feedback. That notwithstanding, good work and great project! David On Mon, 2008-07-14 at 20:05 +0200, Steven Barth wrote: Hello Everyone, you may have noticed LuCI the Lua Configuration Interface in the official release announcement for Kamikaze 8.08 As there was not much information about this project in the past and we noticed several people asking in different places for it we like to make a little announcement here: LuCI is a new approach for a web user interface for OpenWRT. It aims to be free, clean and extensible. While most similar configuration interfaces make heavy use of the Shell-scripting language LuCI uses the Lua programming language and splits up the interface into logical parts like models and views, uses object-oriented libraries and templating. That ensures a higher performance, smaller installation size, faster runtimes and what is most important: better maintainibility. To the project status: LuCI is already quite stable and we are doing last improvements and bugfixes before the first RC version. At the moment all base-system networking and configuration stuff can be edited via LuCI plus a few more applications like firewalling and port-forwarding stuff, a statistics collector with rrdtool-graphs, OLSR and QoS support are included. We are always looking for people to maintain, improve or create web interface components. Maybe you would like to implement a webinterface page for your favorite application: It's not that difficult. If you want to contribute feel free to contact us. Any help whether it may be development, designing, translation or documentation stuff is highly appreciated. You will find all project-related links including a more detailed project description, the sourcecode repositories, screenshots and howtos on our current project website: http://luci.freifunk-halle.net Greetings Cyrus and Jow Lead Developers of LuCI ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
