In addition, the interface is translated into English and Spanish and incorporated into the wikitransalte scheme that uses libremesh.
I had set myself the extra goal of designing the same user interface for LuCi, which unfortunately I didn’t get to implement.
In the interface you can configure a single link (link1), the job that remains to be done is to save multiple links and edit them one by one. It doesn’t mean a great job and I’ll continue it until I do.
Another pending task is to program the administrative pages to be hidden from the menu until the administrator logs in, this is something related to the lime-app design and must be solved. The average user of libremesh does not need to make use of ground routing and therefore displaying it in the menu would only generate confusion and possibly configuration errors.
I want in this last post to thank the Freifunk community, the LibreMesh team and especially Gio for his work as a mentor, he was always there to answer my questions and concerns. Finally, I would like to thank Google Summer of Code for its efforts during all these years and for its commitment to the development of open source software. Thank you very much, everyone.
Hello in this past month I was working on the validation of the configuration in both the front-end and backend.
Basically it is to confirm that the minimum parameters to generate the basic configuration are selected and are of the corresponding type. The double validation is because the ubus module can be used in the future by other applications, and in this way its good use is guaranteed, while validation in the frontend allows a faster response to the user.
View for LuCi
While doing all this I started to develop the basic view for LuCi, although the goal of GSoC is to develop the view for LimeApp I can do both by reusing much of the code. In the next few days I will upload some screenshots.
In this past month I was working on the update of the lime-app dependencies (it was quite outdated). I also worked on the view and the ubus module that reads and saves ground routing settings in the LiMe config file.
It is the minimum configuration of a plugin for lime-app. It has defined the constants, the store, actions (set and get) and basic epics to obtain the data using uhttp-mod-ubus.
Lime-app uses Preact for rendering the views, redux for state management and rxjs-observable as middleware for asynchronous events. For now you only get the setting as a json and expose it to the user.
There are many cases in which equipment attached to libremesh routers is used to make point-to-point links. This is known as ground routing. There is a way to configure routers to work through these links in a completely normal way, without splitting the experience of the mesh. Currently, it requires intervention by using uci commands or by typing the file configuration file directly. The idea is to build a simple configuration screen for LiMe app, which allows users to make use of this feature without major complications.
My name is Marcos Gutierrez, I’m from Argentina and I’ve been working with the Libremesh team for two years. I am a user and member of QuintanaLibre, a mesh network where LibreMesh is used.
Build a ubus module that writes and tests the ground routing settings in lime.
Build a user interface within the LiMe app to configure settings and display alert messages if necessary.
Deploy a use case and validate that it works in the real world.
Bonus: If there is time left to generate a LuCi view with the same capabilities.
In these three months I was working on the implementation of Luci2 (the graphic interface of LEDE / OpenWrt). The project was to translate the functionalities that Libremesh currently uses in Luci to the new proposal. The new environment consists of a backend based on UBUS that exposes JSON with data and the structure of the view.
As far as Google Summer of Code goes, I was able to make the ubus modules that emit information about bmx6, batman-adv, alignment, spectrum analysis, libremap and finally a series of several utilities. The results can be found in the lime-packages-ui repository.
Each module has its documentation on the calls and the expected answers.
Finally I want to clarify that it is my intention to continue until achieving a complete implementation with the front end and keep the packages made. I will adapt the current luci packages to consume the data from the UBUS modules, so its use can be immediate and not wait for the complete development of luci2.
Thanks to the Freifunk community and the Libremesh team for giving me the opportunity to participate in this GSoC. No doubt I will continue to contribute to free software, to have more community and free networks.
At the moment the development of luci2 is found rethinking some decisions and advancing in others. The thread of the discussion can be seen in https://github.com/jow-/luci-ng/pull/42 mainly pushed by @ianchi and commented on by @jow.
For my part I started looking for a mid-point between the LiMe App (developed in preact for LibreMesh) and Luci2. At this moment LiMe App uses orangerpcd in the backend and the same api is being migrated to be consumed from ubus.
The plug-in test for “luci2” in preact can be seen at https://github.com/gmarcos87/preact-luci, although the main development will continue from now on in Agular, but trying to maintain an aprouch where views/apps are Completely defined in json.
I hope to get to the next post with the libremesh api on ubus ready to be consumed by Luci2, whatever their final destination.
In this month I was making several advances in the implementation of Luci2 in Libremesh. Mainly the tasks were to generate a image of the firmware with Luci2 and analyze through a study of the traffic the way in which the rpc acutally builds the menu and manages the ACLs. The idea is to reduce the size to the maximum so that its use is feasible and at the same time reduce the dependency to the frontend frameworks.
All this was possible because I traveled to the Battelmesh in Vienna, where I was able to meet and talk with different members of the team and especially with Jow, who explained the current state of development and put me in contact with other developers. We also talked about possible changes and implementations to ensure some retrocompatibility or at least a simple form of migration from Luci to Luci2.
What am I doing
Provisioning a rendering system on the client based on a JSON structure (not yet fully determined)
Analyzing how to modify the output of CBI so that the output is not an html but a JSON structure
Trying to implement an automatic view generator for exposed elements in uci via ubus and rpc
My name is Marcos Gutierrez, I am from Argentina and this year I participate in the GSoC 2017 in Freifunk. My main task is to incorporate LuCI2 into LibreMesh and to adapt or rewrite the modules that are currently used.
LuCI2 – UI
In my first approach to LuCI2 I realize that there is much more to do than it seemed. The development of Luci2 is still looking for a more stable path, there are good ideas, but a resolution, to my understanding, is incomplete. Only the base UI build weighs 1.4MB, this far exceeds what LibreMesh requires. So I should explore some alternatives to drastically reduce the size.