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
