5 Jun
2017
5 Jun
'17
1:08 p.m.
On 05/06/17 14:07, Daniel Golle wrote:
Hi!
Hi Daniel.
I finally got to the point to test the results of
running 802.11s on
plain LEDE and want to switch to the upcoming LiMe release and help
testing. As most of the folders on the release download server are
still empty I liberated enough free space on my SSD to build the SDK
and IB from scratch myself. The good part: Congratulations for
switching to the IB+SDK and starting a more productive colaboration
with the upstream projects! It's great to see that the Libremesh
fishtank has finally poured into the open sea :)
In the next week I'll be working on a test-deployment which will be
based on the upcoming LiMe release and hence LEDE-17.01.2(-pre) on a
Lantiq XRX200 device providing a VDSL gateway plus a bunch of ar71xx
devices providing the mesh+APs. I hope that we can then annouce to have
sucessfully overcome the boundaries of only using only one hardware
platform. And make the switch to 11s (which I'll be using there as
well)
Good! I think we are going in the good direction.
The rather sad part of the tour through the upcoming
release was to
find 'libusys' which was apparently pulled in by 'organge-rpc':
Please take a look the code at
https://github.com/mkschreder/libusys/tree/master/src
Did you notice that this is someone trying to recycle Felix code' from
5 years ago? And never send a single message to the upstream mailing
lists or ever tried to contribute just one line?
Besides that, it's also sad in terms of making best use of our scarse
flash and memory resources, because we already got everything which is
there (uloop, ulog, ...) and need it anyway for procd, netifd, ...
Now have a look and compare with the above:
https://git.lede-project.org/?p=project/libubox.git
https://git.lede-project.org/?p=project/ubox.git
https://git.lede-project.org/?p=project/ustream-ssl.git
(and some more)
Why on earth include it again, in an outdated version?!
To me it was quite shocking to see that you are using weird outdated
stuff which is featured by an isolated one-man-show rather than
participating in the much wider and public collaboration. If you really
need websockets, why not attach them to uhttpd (I didn't quite
understand why you need them in that context I must admit)?
If you want a JSON-RPC, why not use uhttpd-mod-ubus?
This packets are only used if lime-ui-ng (new webSockets interface and
Android APP) is selected, but not for the standard libremesh packages.
Lime-ui-ng [1] is in a very initial development, at the beginning we
found JuCi [2] and we tried to reuse the work done. Afterwards we
realized it was not a good idea and we are now in the path to get rid of
it (and use LuCi2 ubus-rpc instead).
As we needed something working (because of some deadline on the
schedule) we are still using it. But most of the efforts are put on
something which is not attached to all the mkschreder code and it will
be easy transported to Ubus and standard LEDE packages.
So don't worry it is just something temporally and if you are not using
the lime-ui-ng stuff (which is only used in some Argentina community) it
does not have any implications.
[1] https://github.com/libremesh/lime-ui-ng
[2] https://github.com/mkschreder/juci
Anyway. It somehow happened. What's the plan and
how to proceed with
the lime-ui story? Maybe I'm just lacking information...
The GsOC from Marcos (Luci2 on LibreMesh) and these days at the WBM in
Vienna will change the course of lime-ui, for sure.
Cheers
Daniel
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
--
./p4u