> It's just a separate set of packages: not more, not less. > Ok, cool.
> 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. > 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? > Yeah, sounds like many scripting languages... > 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 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. > Right, but an issue with UCI is because of it's flexibility, there are variations in the configuration between sub-projects of OpenWrt. That was a natural consequence, but still poses problems when referring to UCI as 'standardized'. > 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. > 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. Yet, what you are building is not _just_ a user interface. It is a configuration engine for UCI (and the applications available on OpenWrt). As such, it is too bad it (the advanced logic part) can't be used outside of the GUI framework... or can it? David _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
