30 Jan
2015
30 Jan
'15
11 a.m.
Yesterday I tested the current implementation of the web interface LUCI2
[1] (which will replace LUCI in the future). The basic administration
menu (Network, WiFi, System, Status, etc.) is already implemented and
works fine.
LUCI2 is a 100% rewritten web interface and it does not use lua anymore.
It is just a small uhttpd plug-in which communicates Javascript with
ubus via standard JSON. So it is quite more flexible and less resources
aggressive for the router (since the JS is executed in the client side).
I would recommend to start thinking in LUCI2 instead of LUCI, so we
should base the future LiMe web interface in LUCI2. Would be nice to
have some JavaScript expert into the team :)
Cheers.
[1] http://wiki.openwrt.org/doc/techref/luci2
--
./p4u
30 Jan
30 Jan
4:50 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/30/2015 08:00 AM, Pau wrote:
Yesterday I tested the current implementation of the
web interface
LUCI2 [1] (which will replace LUCI in the future). The basic
administration menu (Network, WiFi, System, Status, etc.) is
already implemented and works fine.
LUCI2 is a 100% rewritten web interface and it does not use lua
anymore. It is just a small uhttpd plug-in which communicates
Javascript with ubus via standard JSON. So it is quite more
flexible and less resources aggressive for the router (since the JS
is executed in the client side).
I would recommend to start thinking in LUCI2 instead of LUCI, so
we should base the future LiMe web interface in LUCI2. Would be
nice to have some JavaScript expert into the team :)
I agree, if LUCI2 is being actively developed, we should focus on that.
I had lots of experience with JavaScript long time ago (jquery did not
exist!), but I may be able to at least help with this.
cheers,
Nico
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
iQEcBAEBAgAGBQJUy7YMAAoJEPHORz17N0TFS6QIAKMjJ5APJn+Uabww1u17O6Yi
QG0jbLc01U3I0SXsBA2GwdWSaN7+/OXUwsLp0aDgZcoO52bBSuA2UfXoCHDPUDRS
e826OJjN1NrUqYdAwLqGr7cFs/lDfvIxtvrWJexvQZOwUDPc5tJPJovTVdwu37lN
DRfqnUUbGVhP3gL+HFP2Azk/0Et9RRiCd30RU5Zhi4mrCCOyXWfVbqC1IdZhD8z8
ppzX7V+S7vjOVhI2dy6KMV8i0vWjo7SLYeOAXHH33V9cao08pA4BFFnGfxYJqONQ
9/2X8K5G5ysW7tQY0UiCmizAgpnz8EXg620oD0Gv9d3IS3BSvLDf5u3MaKsS3VU=
=5PJY
-----END PGP SIGNATURE-----
6:12 p.m.
On Friday, January 30, 2015 12:00:29 PM Pau wrote:
Yesterday I tested the current implementation of the
web interface LUCI2
[1] (which will replace LUCI in the future). The basic administration
menu (Network, WiFi, System, Status, etc.) is already implemented and
works fine.
LUCI2 is a 100% rewritten web interface and it does not use lua anymore.
It is just a small uhttpd plug-in which communicates Javascript with
ubus via standard JSON. So it is quite more flexible and less resources
aggressive for the router (since the JS is executed in the client side).
I would recommend to start thinking in LUCI2 instead of LUCI, so we
should base the future LiMe web interface in LUCI2. Would be nice to
have some JavaScript expert into the team :)
This is related to the removing of part of the API like Hex() ip constructor
and so on?
What should we do at this point? On our code we rely on luci-lib (the one
written in lua) should we consider that openwrt folks will drop those
libraries soon or later ?
Should we repackage some lib like nixio that we are actually borrowing from
luci?
For the moment i believe we should have our how clone of luci repo with HEAD
fixed to the last point it is compatible with our code, and refer to luci2 for
future development not for the actual stable release
1 Feb
1 Feb
11:45 a.m.
On 30/01/15 19:12, Gioacchino Mazzurco wrote:
On Friday, January 30, 2015 12:00:29 PM Pau wrote:
+1
Yesterday I tested the current implementation of
the web interface LUCI2
[1] (which will replace LUCI in the future). The basic administration
menu (Network, WiFi, System, Status, etc.) is already implemented and
works fine.
LUCI2 is a 100% rewritten web interface and it does not use lua anymore.
It is just a small uhttpd plug-in which communicates Javascript with
ubus via standard JSON. So it is quite more flexible and less resources
aggressive for the router (since the JS is executed in the client side).
I would recommend to start thinking in LUCI2 instead of LUCI, so we
should base the future LiMe web interface in LUCI2. Would be nice to
have some JavaScript expert into the team :)
This is related to the removing of part of the API like Hex() ip constructor
and so on?
What should we do at this point? On our code we rely on luci-lib (the one
written in lua) should we consider that openwrt folks will drop those
libraries soon or later ?
Should we repackage some lib like nixio that we are actually borrowing from
luci?
For the moment i believe we should have our how clone of luci repo with HEAD
fixed to the last point it is compatible with our code, and refer to luci2 for
future development not for the actual stable release
3 Feb
3 Feb
7:28 p.m.
I don't think they are gonna remove luci-lib and so on, there are many
applications which are using it. However we may ask it to the luci
developers to be sure which are the plans for it.
On 30/01/15 19:12, Gioacchino Mazzurco wrote:
On Friday, January 30, 2015 12:00:29 PM Pau wrote:
--
./p4u
Yesterday I tested the current implementation of
the web interface LUCI2
[1] (which will replace LUCI in the future). The basic administration
menu (Network, WiFi, System, Status, etc.) is already implemented and
works fine.
LUCI2 is a 100% rewritten web interface and it does not use lua anymore.
It is just a small uhttpd plug-in which communicates Javascript with
ubus via standard JSON. So it is quite more flexible and less resources
aggressive for the router (since the JS is executed in the client side).
I would recommend to start thinking in LUCI2 instead of LUCI, so we
should base the future LiMe web interface in LUCI2. Would be nice to
have some JavaScript expert into the team :)
This is related to the removing of part of the API like Hex() ip constructor
and so on?
What should we do at this point? On our code we rely on luci-lib (the one
written in lua) should we consider that openwrt folks will drop those
libraries soon or later ?
Should we repackage some lib like nixio that we are actually borrowing from
luci?
For the moment i believe we should have our how clone of luci repo with HEAD
fixed to the last point it is compatible with our code, and refer to luci2 for
future development not for the actual stable release
3379
days inactive
3383
days old
4 comments
4 participants
participants (4)
-
al -
Gioacchino Mazzurco -
Nicolás Echániz -
Pau