Category: Allgemein

TX-power control in WiFi networks – GSoC’22

Posted on by jonas.jelonek

Hello everyone!
My name is Jonas and I have the opportunity to be part of GSoC’22 cycle. With this first post I would like to introduce me and my project. The essence of the project is to provide and evaluate an implementation for TX-power control in the WiFi subsystem of the Linux kernel.

About me

I’m Jonas Jelonek and I recently finished my bachelor degree in ‘Automation and Electronics Engineering’ at the University of Applied Sciences Nordhausen in Germany. This summer I have some free time before I will begin my master studies in October, which I will spend on realizing my GSoC’22 project.

Coding has been a passion of mine for a long time and I have always been a fan of open source software (OSS) and hardware as they usually provide more possibilities and benefits as their proprietary counterparts. OSS is ubiquitous in my environment as I love both to use and to contribute to OSS, and also to share my code with others. During my studies, I had the opportunity to extend my knowledge and coding skills, and also to get more in touch with open source projects. I am involved in projects targeting research whose achievements are later going to be available open source.
Besides, I also had the honor to visit conferences like MECO, SSEA and ESA PAC which aim at sharing knowledge and expertise in fields of hardware and software engineering and offer the possibility to get in touch with scientists and engineers from other countries.

My motivation

My motivation mainly comes from a research project I have been part of since 2020. This project aims at developing, implementing and evaluating new and improved resource allocation algorithms for WiFi networks. As WiFi networks are becoming more and more important, the same applies to their reliability and performance and the efficiency of the underlying hardware. TX-power control (TPC) is a way to improve this by adjusting the transmit power per packet or per multi-rate retry (MRR), resulting in overall higher throughput in wireless networks and/or higher efficiency by optimized resource allocation.

Beginning in 2007, Atheros 802.11a/b/g/n chipsets (driven by ath5k and ath9k Linux drivers) started to support TPC in hardware, followed by Mediatek recently. They allow to set the TX-power per packet, but yet do not provide a driver interface for this in the corresponding Linux drivers. Unfortunately, also the mac80211 subsystem, which is responsible for WiFi communication in the Linux kernel, does not provide an appropriate API to support TPC and per-packet/per-multi-rate-retry annotation of TX-power.

I want to change that! I want to provide a proper TPC API for the Linux kernel to extend its support in several devices and to allow several projects to research the improvements and opportunities of TPC for wireless networks.

What we want to achieve …

Main goal of this project is to implement the missing three-tier software parts that make TPC for WiFi hardware in the Linux kernel possible:

  • (1) mac80211 structs to annotate TX-power levels per packet
  • (2) mac80211 structs to account TX-power status information once transmitted
  • (3) a TX-power control (TPC) API for TPC algorithms

This is achieved by developing and implementing the required structs in the mac80211 subsystem. These steps are subject of the first milestones and will be worked on in phase 1 of the coding period.

In addition to this, I will modify several Linux WiFi drivers to make use of this API. In the beginning we target to use ath9k and mt76 WiFi drivers for Atheros and Mediatek hardware. This hardware will then be used to test and validate the implementation in several experiments. These further changes and the evaluations are part of phase 2 of the coding period.

What we have done so far …

Usually, some time passes between the submission of a patch to the kernel mailing list and its final integration in a kernel release. We have already been preparing the implementation of TPC in the Linux kernel for some time with some patches .
Before GSoC I already worked on ath9k and ath5k Linux drivers, changing the way those two drivers receive TX rates from rate control algorithm to use the latest mac80211 structs instead of legacy ones. This simplifies further adjustments mandatory for TPC during the GSoC project. The corresponding patches were posted on the kernel mailing list in Nov 2021, and were included in the Linux kernel release 5.16 in Dec 2021. (commits 7f3a6f5dd207ecd582e1f02ebdb498493770a490 and a5d862da91058a855ab00bf46b5383543bbf3979)

In May 2022, I implemented changes in the TX status path of the mac80211 subsystem, minstrel_ht rate control (RC) and two WiFi drivers, and proposed them as patches on the kernel mailing list. They already include a new struct that allows the usage of all MCS rates (including 802.11ax and above, before only up to 802.11ac) and TX power annotation in status path, changes in minstrel_ht to make use of these changes and resulting changes in WiFi drivers mt76 and ath11k. These changes were approved within short time and will be included in the upcoming release 5.19 of the Linux kernel. (commits 44fa75f207d8a106bc75e6230db61e961fdbf8a8 and 569cf386ec5f4619388ae0c62169175dc2804f32)

In the community bonding period, I discussed the project objectives with my mentor and we made a plan for the upcoming steps of the project. After that, I started to work on the structs and their implementation that are part of the first milestones of the project.

What’s next?

As already mentioned in the text, there are several steps to work on and it’s a tight schedule. I already started to work in the structs and their implementation, and this will also be the task for the following weeks. This usually takes some time to develop a proper and well-thought design.
But I also the integration of this API into the already mentioned drivers will be begun in by the end of this period.

That’s my project!
I will keep you up to date with the progress. Keep watching!

Thanks for reading!
Jonas

Call A Friend – GSOC’22

Posted on by AdiCoder

Introduction

The existing version of Messenger app has some bugs related to connectivity and exit, the UI is a bit old and the codes are written in Java. This GSOC project aims at converting the whole source code to kotlin, improving the UI, fixing bugs and making a stable release for the app.

About Me

Hello everyone

I am Aditya Khandelwal, First year college student pursuing B. com hons in Accountancy, programming is my hobby, I am good at developing android apps with kotlin. I love to code, being a part of GSOC’22 would help me get experience with open source Development.

Project Goals

My goal is to fix bugs in the existing version of Meshenger app, convert the codes to kotlin and make a stable release for the app.

Decision after Community bonding period

I would start with making a cleaner UI for the app then I will convert the whole codes to Kotlin, implement the new UI and work on fixing the bugs along with frequent testing.

My experience

In the Community bonding period I familiarised myself with my mentors, got insight about how the app was initially developed, what we are looking forward with the app and so on.

I also got valuable feedback and suggestions on planning the working model.

I am really excited to move forward with the coding phase.

Completing the Retroshare Web Interface – GSOC’22

Posted on by SukhamjotSingh

Introduction

The Web interface for Retroshare Application is under process. Many features are functional but there is still a lot of work to do and fix. This GSOC project aims at developing the web interface to a certain extent and include as many missing features as there are in the Retroshare QT interface.

About Me

Hello Everyone,

I am Sukhamjot Singh, a 4th-year undergraduate in Computer Science at International Institute of Information Technology Bangalore. I love 2 things – Table Tennis and Open Source development. The fact that my contribution, however small or big, will be a part of something huge and useful, motivates me to work further.

Project – Goals and Deliverables

Homepage of Web Interface.

The Web interface for Retroshare is made using MithrilJS ( a lightweight Javascript framework ) and the backend is mainly supported through the use of Retroshare QT interface and JSON API that is already available. Frontend design will be consistent with the already present features.

Major deliverables: The major deliverables will be in form of tabs which mainly include:

  • Files
    • File Manager
    • Uploads
    • Search
  • Forums
    • Navigation Bar for different categories of forum.
    • Displaying forums info
    • Search
  • Channels
    • The layout is same as forums.
    • Display posts, files, info of the channel
  • Configuration
    • This tab helps to configure Retroshare App
    • Config options for Network, People, Mail, Files etc.
    • This needs further discussion with the mentors.

Further objectives also include solving some of the issues in the features that are already present. Working on existing Github issues is also a priority.

Community Bonding period – First two weeks.

In this period, I have familiarized myself with the mentors ( Cyril Soler and Gio ) and discussed the goals and objectives of the project. I have started developing the Channels and Forums tab and have completed the basic layout. All of this work is done in a separate branch on my fork of the repository.

Ongoing Pull Request : https://github.com/RetroShare/RSNewWebUI/pull/51

My fork : https://github.com/Sukhamjot-Singh/RSNewWebUI

The updates about the development are regularly provided on Github and to the mentors. There are also weekly meetings being scheduled to report the progress of the project with the mentors. I will also post more blogs for further developments.

The process of contributing and getting selected for Google Summer of Code’22 has been thrilling and I wish to have an exciting summer with Freifunk – Retroshare and my mentors.

Finishing an app for network capability for the LibreMesh OS

Posted on by Tomás Assenza

Hi! I’m Tomás on my last post about the LibreMesh Application (now just LimeApp). It was really fun to work with Altermundi on this project and I like the results that we achieve. I hope that everyone enjoys this post just like I enjoyed working on the application! So, let’s get started.

Finished the first part of the GSoC we started to build the next version of the app (1.0).

Resume

As a resume, the objectives for this part are:

  • Do a correct use of threads trying to avoid interruptions to the user.
  • To implement a new Graphical User Interface with the capability of returning messages to the user about the situation of the network (for example, could the app connect to thisnode.info? No? Why?).
  • Add the app to the LibreMesh Operating System.

Fixing the HTTPGet

First things first the previous app had a bug discovered at the first meeting of the second part. If someone has a server on the address thisnode.info the connection could be reached and, in this case, the app shows that the connection to LibreMesh was correct in all the possibles cases.

So, the solution is to do an HTTPGet to thisnode.info. There’s an interesting answer in StackOverflow about this topic:
https://stackoverflow.com/questions/2793150/how-to-use-java-net-urlconnection-to-fire-and-handle-http-requests

So, we will only focus on getting an HTTPGet, so with the tools that we got from the article, I built this code:

StrictMode.ThreadPolicy policy = new StrictMode.ThreadPolicy.Builder().permitAll().build();
StrictMode.setThreadPolicy(policy);

try {
    connection.getInputStream();
    return true;
} catch (IOException e) {
    e.printStackTrace();
    return false;
}

Using threads

This code looked fine but there’s one thing that wasn’t correct according to the Android specifications. There’s a permitAll in the policy. This means that connections can happen in the principal thread of the application. To publish in the play store, we needed to change this and create a thread to run the HTTPGet, so the code now looks like this:

boolean[] success = {false};

Thread connectionThread = new Thread(new Runnable() {
    public void run() {
        try {
            connection.getInputStream();
            success[0] = true;
        } catch (IOException e) {
            e.printStackTrace();
            return;
        }
    }
});

    connectionThread.start();
    connectionThread.join();

    return success[0];

This isn’t the best example of a Thread cause doesn’t work concurrently, but it helps the app to respect the Android specification.

Thanks to our testers, we discovered that there was a problem with the latest Androids version that required too many permits to access the SSID or even the ID of the WiFi, so we decided to disable the verification that used these attributes in the latest version of Android

public static boolean verifyWifiConnection(WifiManager wm) {
    if(Build.VERSION.SDK_INT <= Build.VERSION_CODES.P)
        return wm.isWifiEnabled() && wm.getConnectionInfo().getNetworkId() != -1;
    return wm.isWifiEnabled();
}

Also, we needed to add the attribute android:usesCleartextTraffic=”true” in the Android Manifest because the latest Android version doesn’t allow HTTP sites on WebView.

Finally, we added an error screen and changed the use of the app from three buttons to an “automatically display” of the Lime-App, or an error message.

Graphical interface

We wanted to maintain the app light, so the graphical interface needed to be only two screens:

  • One with the WebView that access to the LibreMesh configuration.
  • Other one with an error and some tips to fix it.

So, with these use cases, we created an error screens that looks like this:

Error screen of the LimeApp

And here’s a video of how’s the app working:

Unit testing

With all the problems solved and the testers using the prerelease version, we added some unit testing using Mockito. This is an example of a Unit Test of a correct connection to the app:

@Test
public void correctConnection() {
    when(wm.isWifiEnabled()).thenReturn(Boolean.TRUE);
    when(wm.getConnectionInfo()).thenReturn(wi);
    when(wm.getConnectionInfo().getNetworkId()).thenReturn(1);

    try {
        when(urlc.getInputStream()).thenReturn(null);
    } catch (IOException e) {
        fail();
    }

    MainActivity ma = new MainActivity(wm, urlc);

    assertEquals(true, ma.accessToLibreMesh());

}

This test uses mocked objects to simulate a response and then it executes the function. We plan to add in the close future Integration tests.

Reducing the app size

One of the objectives that we set for the second part of the GSoC was to reduce the APK size to add the app to the LibreMesh OS. The original size was 2.91 MB and knowing that a LibreRouter has 8 MB of total space, uploading the app means to use 36% of the node space.

The first attempt to reduce the APK size was to start using the “Generate APK” function of Android Studio instead of using the debug APK. This is also needed to sign the app to publish in the Play Store. This reduced the size from 2.91 MB to 2.42 MB.

This reduction was great but isn’t enough, so we started using the tips of the ApkGolf project (https://github.com/fractalwrench/ApkGolf/b) to reduce the space. In an ideal case, we could use all of them, but we wanted to maintain things like a Constricted Layout for the Error message.

We started adding some lines to the build.gradle that add scripts that help to reduce the code and resources size.

buildTypes {
    release {
        minifyEnabled true
        shrinkResources true
        proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
    }
}

(The proguardFiles were already in the code, but also helps in the size reduction).

Another interesting setting is the resConfig. The library imports usually bring support for multiple languages. We’re currently using Spanish, so setting this to only one language reduce the size a little

resConfigs "es"

Another thing that reduces space is to convert the images to WebP (and accept a good percentage of reduction of quality). We also deleted some files and hard-coded things like the colors (to remove de .xml).

The file that occupies the most space is the one that’s related to classes (ours and imports), so the best way to reduce space use was to remove them. In the build.gradle there were a lot of imports that we added in some moment, but we removed the use of them, so remove also from the build.gradle was a good idea.

They were particularly two interesting dependencies:

implementation 'androidx.appcompat:appcompat:1.2.0'
implementation 'com.google.android.material:material:1.2.1'

The first one was added by Android Studio and we didn’t use it, but the second one was an addition to the design of the application. We removed the calls to the import and the dependency. That reduced approximately 400 KB of space.

At the end of the process, the APK size is 730,337 KB, this means a reduction of approximately 85% of space use.

Finally, we decided to publish a close version to the Play Store because all the main objectives were completed. Currently, we’re waiting for Google to finish the revision on the App.

Jekyll page

We’ve also added a Jekyll page for the project (available on Github) that shows some information about the application and the problem that solves.

Github page of the project

Link to the Github project

I’m really happy with the work that we did during this GSoC and I’m glad that this application is going to help Community Networks around the world. Thanks to all for letting me be part of this great community and especially to Nicolas Pace and Germán Ferrero for all the support that they gave me during this two months. Greetings and I hope that I can help with other open-source projects in the future!

GSoC Final Blog-OpenWrt Device Page

Posted on by Aditi

Greetings! Hope everyone is staying safe! 🎉

I am Aditi, and this is my last blog post for Google Summer of Code 2021!

As this journey comes to an end, I would like to summarise the wonderful experience I’ve had over the period of 10 weeks. Though, my interaction with OpenWrt has been before that, and I am positive, this is not the end of my contributions to the wonderful community!

Google Summer of Code with FreiFunk

Before talking about the details of my project, I would like to write a small acknowledgement of my 10 week journey.

It has been a really exciting journey! I learnt more about Git/GitHub and React in these 10 weeks than I had learnt in past one year of working by myself. GSoC allowed me to improve my communication skills by talking in communities!

These 10 weeks working with FreiFunk(OpenWrt) finally enabled me to get over my impostor syndrome. The mentors and admins have always been helpful even after I made quite a few mistakes in a few commits.

I would like to thank the community for tremendous amount of support and patience! 😊

Project Progress

The project repository can be found here.

So, as per my first blog, we planned on achieving the following over the summer:

The main aim of OpenWrt Device Page Project is to create an overview of OpenWrt supported devices to simplify user choice of acquiring new devices. The project can be broken down into two major sub-tasks:

  1. Creation of input form from a JSON Schema to simplify the process of adding device metadata to the github repository.
  2. After creation of input form, the second step is to render the device pages. The device pages will have search masks, to search specifically for devices with certain features like USB port, WiFi6 etc.

The form has been build with the autocomplete functionality (which has been quite a challenge!). However, there are still some issues that need to be fixed.

Future Scope

One of the major next steps of the project is to use the device data to create device pages. The device pages would have search option to search devices on the basis of USB Port etc.

[GSoC’21] RetroShare Mobile : Final Evaluations

Posted on by Avinash Kumar

Prologue :

Hello everyone 👋

This is the final update on the GSoC 2021- Retroshare Mobile App Project.

Recap :

The goal of the project in the second half was:

  • Created a new flutter retroshare API wrapper package.
  • Adding support of image in Chat.
  • Added Shimmer Effect for better UI interface.
  • Adding forums Support in Retroshare Mobile.
  • Embedding retroshare service inside the retroshare mobile using QT.
  • Converting retroshare service from background to foreground service.

Achievements :

  • Image support has been added in Chat.
  • Created a Retroshare API Wrapper package.
  • Added Shimmer Effect.
  • Added all the related API’s in Retroshare API Wrapper dart package for forum Supports.
  • Embedded the retroshare service inside the retroshare mobile using QT.
  • Converted retroshare service from background to foreground service. (InProgress)

Group Chat

Screenshot 2021-08-16 at 11 27 00 PM

Distance Chat

Screenshot 2021-08-16 at 10 13 53 PM

Related Patches :

Challenges encountered :

Retroshare service a.k.a backend of retroshare mobile was compiled in 2019. So, it was some compilation issue with the new mobile phone which is launched after 2019. For overcoming these issues, I had to find the reason and solution to this problem. That solution is something on which I didn’t work before. So, it took me a long time to understand and still it is not working properly. But I will solve this problem soon.

Future Plans :

  • Adding of Forum suppport.
  • Improvement of UI/UX.
  • Support of CI/CD pipelines.

Conclusion:

During this program, I learnt many different things ranging from tools to technologies.

There is still some work needed for the project, which is why I’ll keep on working on it. Contributions, suggestions and feedback are always welcomed.

At the end it is just the beginning of another journey. Good day and fare the well everyone.

GSoC – 2021 OpenWRT PPA final evaluation

Posted on by Neelaksh Singh

Hey all hope you all are doing. With heavy heart I would like to conclude this beautiful journey of GSoC 2021 with one last blog.

First I would like to start by thanking Freifunk, Google and my mentor Mr. Benjamin Henrion for guiding me to become a better developer during the course of this program.

The link to my work can be accessed from here

Work done till now

As stated in the first blog, the main project revolved around making a working OpenWRT SDK available to users with an abstraction layer for their easy use.

First order of business was to present the user with a web interface where they just have to provide with their repository link, which can then be build using the OpenWRT SDK and final packages and targets could be hosted on a server.

The website looks like :-

The final build are hosted on a httpd server running on the background

Challenges encountered

During the development of this project the issue I faced was that of building the user scripts in the docker container containing the SDK. Also the default config file had to be implemented to override the menuconfig settings.

To overcome this I created a docker image containing the SDK which automatically builds the user packages. You can find it here.

The second challenge was for the build container to run in the background, without disturbing the the web-interface functionality.

For this I have used multiprocessing module and subprocess’s Popen module respectively. What they do is simply create a separate process for build step and running it parallelly alongside the web-interface thereby achieving concurrency.

Future Plans

  1. Improve Web-portal with added UI/UX
  2. Finding more ways to host these packages.
  3. Improving the build process by running them in Kubernetes cluster.
  4. Having a provision for multiple builds.
  5. Possibly include CI/CD pipeline for the same.

Conclusion

During this program I learnt many different things ranging from tools to technologies.

There is still a lot to be achieved for the project, which is why I’ll keep on working on it. Contributions, suggestions and feedback are always welcomed.

At the end it is just the beginning of another journey. Good day and fare the well everyone.

LibreMesh Pirania UI – A final overview

Posted on by Angie Ortiz Giraldo

Hello Freifunk community!

Working on this project has been amazing, not only have I been able to work hand in hand with great developers but I have also learned a lot of things related to software development that will probably be useful for me in the future. The main idea of this project seeks to improve the implementation of the administration interface of the Pirania captive portal which is implemented in LibreMesh, a plugin used in different Community Networks.

During these weeks, I focused on 3 aspects: design, testing and implementation.To create the sketches that would allow me to detail the achievement of our ideas, we chose a tool called Figma, in this I could deploy the initial designs that we plan to implement for this project. Below you can see some of the screens I created:

List of vouchers screen

In this first screen we thought of some functionalities such as being able to search for vouchers, list vouchers and access another screen to create vouchers, when we choose the option to create vouchers we will see a screen like the following one:

Voucher creation screen

In this screen you can find some functionalities such as:

– Description field, to identify who the voucher is for or what it is used for.

– Choice of the duration time since the voucher activation.

– Choice of voucher permanence, to establish whether a voucher can be used for “unlimited” time or not.

– Possibility to choose how many vouchers to create.

– Possibility to edit a voucher created to correct any typo in the description or to “delete” a voucher so that it can no longer be used.

– And set the possibility of choose some other advanced options such as setting an expiration date to activate the vouchers.

– At the end of the voucher creation, generate a metadata page to deliver the voucher passwords and other data of interest such as the description and the voucher creation date.

Voucher details

In this screen we access after selecting a specific voucher in the voucher list and we can find some features such as the availability status, the creation date and the password that enables access.

As you can see, the idea of these screens is to maintain a similar and clear aesthetic, just like the LimeApp.

After that, I was working on a TDD framework to write the tests for these screens, I used technologies like React Testing Library and Jest. screens, I used technologies like React Testing Library and Jest.

Working on these tests was my favorite part of the project, as I feel that I was able to learn many things in this area and discover tools that I did not know.

Currently this project is at this point, however, I will continue working on new updates to implement all these ideas that I have been working on these weeks.

Finally, I want to thank Freifunk and my mentors for helping me in this process, it has been very rewarding for me to share and learn so much from them!

Thanks for reading,

Angie.

[GSoC’21] API Generator and tools with Draft-7 JSON schema

Posted on by sh15h4nk

Before you ingress

Hello everyone!, The main intention of this project is to update the existing API spec schema files to the latest version of JSON schema, and also few tools which are dependent on the spec files.

The current latest version of JSON schema is version 2012-12, but unfortunately there isn’t much support to update the dependent tools(to be specific, the generator). So my mentor Andibraeu and I have chosen to work with draft7 version, as it has upper hand with implementation support compared to other recent versions.

Our initial map out

  • Migrate all the spec schema file to draft 7 version.
  • Pick out a framework to update the generator.
  • Generate and test the forms.[1]
  • List and update all the remaining dependent tools.
  • Test the updated tools.
  • Fix bugs, if any.

Spec files

Migrating the spec files to draft 7 version is not a difficult task. At the beginning, I have only migrated the recent version of spec file, so that we can immediately start working with the tools. And after updating all the tools, I have migrated all the spec files to draft 7 version.

Some features to point out:

References:

  1. Initial Migration -pull request
  2. Patch -pull request
  3. Patch -pull request

Generator

This is one of the significant tool depending on spec schema files. The job of the tool is very simple, it takes JSON schema as input, generates HTML forms to render in the browsers, handles validation of the form data against the input JSON schema and finally, generates a JSON out file.

Generator Layout

Unfortunately, no framework seemed perfect at the beginning, so I have picked up several frameworks to try them out and weigh the pros and cons to finally pick one. I had mentioned all the pros and cons in a document(check the references section).

Frameworks that I have tried

  • UI Schema for React
  • React JSON schema forms (mozilla)
  • Restspace Schema forms
  • JSONForms (Eclipse Source)

By weighing all the pros and cons, we have chosen JSONForms (Eclipse Source) to proceed with the further development.

JSONFORMS (Eclipse Source)

And thereafter, I developed UI schema for custom layout for the form field in the webpage. Also, at this point, I have to develop a custom renderer to render a map for picking the latitude and longitude of the communities locations. So upon looking at the documentation I developed the custom renderer (renderer, control and tester) thereafter to adopt this renderer to schema we need to have single object which only embeds longitude and latitude fields. So I quickly discussed with my mentor and added a new spec file to the organization. In conclusion, we have our generator up and running a demo in GitHub Pages.

References:

  1. Evaluation of frameworks -document
  2. Implemented frameworks -repo
  3. Generator tool -repo
  4. live demo -GHPages

Dependent tools

The API viewer and the Travis job CI are completely dependent on the spec schema files to validate the communities API files.

API Viewer

This tool generates a static build of pages, which show the validation result of the communities API file data.

A Valid API file
An Invalid API file
Validation Errors

Improvements:

  • The prior tool existed in python 2, I have updated to python 3.
  • Update to Validate data against draft 7 schema and show validation.
  • Added datatables to list the communities.

References:

  1. Python 3 migration with Draft 7 data validation -pull request
  2. Patch -pull request

Travis Job

All the API files are collected in the directory repository. And this Travis job validates the data of the API file data, when they are updated or added to the directory.json

Travis job Build
Job console output

A build of the travis job can be found here.

Improvements:

  • Also, this tool (test) existed in python 2, I have updated it to python 3.
  • Updated to validate data against draft 7.

References:

  1. Python 3 migration with draft 7 validation -pull request

Common API(collector script)

If you recall as I have added new spec file by embedding latitude, longitude into an object to adopt with the jsonforms custom renderer for map picker using react-leaflet. This would affect a lot of other tools like Community finden, Kontakt, etc which are truly based on the lon, lat fields of the API files. But luckily all these tools use a summarized API file, And the collector script is used to collect all the communities files.

Improvements:

  • Deserialized geoCode object and appended the fields to the respective locations. So that the fields are set to their old locations.

References:

  1. Altering Location fields -pull request

References

Here are the previous blogs of the project at different stages:

  1. Initial Stage(Before coding period)
  2. Phase I evaluation

Wind-Up

I have started the project with minimal understanding of react, typescript and jsonschema. But it was very fun to understand and work on. I really liked this way to learn new things rather than reading or doing a course. Every issue that I have encountered had leaded me to understand the things briefly. I’m really thankful to freifunk for the opportunity. And a big shout out to my mentor Andreas Bräu for absolutely wonderful guidance and support.

~ Shiva Shankar aka sh15h4nk