If you follow this blog, you already know that there's a native Thunderbird add-on in the works (hopefully with a version out soon), and probably GNOME (Evolution) and KDE integrations will be worked on in this summer's Google Summer of Code and Outreachy. After these projects are finished, users of the above desktop clients won't need the DAV bridge anymore, and can just use EteSync directly!
Even with these exciting projects in the works, we still haven't forgotten about the desktop DAV bridge! The DAV bridge is still needed for applications where EteSync isn't, or can't be, supported natively such as Contacts.app (macOS) and Outlook (Windows).
There have been a few major improvements to the desktop DAV bridge, recently, here are the highlights.
Initialise new accounts
Since EteSync is end-to-end encrypted, the server can't access user data. This is a great thing, and why we created EteSync in the first place, however it also means that most of the logic needs to be implemented in every client, and this includes the DAV bridge.
Specifically, until recently the DAV bridge would not initialise new accounts, but instead just assume that the account has already been initialised by another client, such as the Android or the web one. Most people wouldn't even notice it because they use multiple clients anyway, but those that were using EteSync only on the desktop needed to first login from another client in order to properly use EteSync.
Not having to open another client makes the on-boarding for new desktop-only users much smoother.
Management UI improvements
The desktop DAV bridge can be configured in one of two ways. The first is using the command line interface, and the second (recommended) way is through the web management UI. We made a few improvements to the management UI recently, but the most notable one is the unification of the DAV server with the management UI server.
Before this change, the main DAV bridge url was http://localhost:37358 and if you opened it in the browser, it would redirect you to http://localhost:37359 which was the management UI. Notice the slightly different port numbers. A lot of people found this very confusing, and more than once we saw people trying to use the wrong URL in their DAV clients.
It took a bit of tinkering, but we finally managed to get both services to run from the same port (and thus URL), with the management UI being redirected to automatically when opened from the browser.
A few more bug fixes and improvements
We fixed an issue that was causing a high CPU usage when there was no internet connection. The issue was in the error-recovery logic. The DAV bridge is designed to try again on error and wait a certain amount of time between retries. However, in some cases it would skip the wait and get into a loop of trying and failing, driving up the CPU usage.
We also fixed an issue with the local cache getting locked which could cause syncs to fail with multiple concurrent requests. This was because we were using the underlying database (SQLite) instead of the more appropriate WAL mode.
In addition, we also changed the location of the DAV bridge's data directory. Due to legacy reasons, the DAV bridge was saving its data in the user's configuration directory (~/.config/etesync-dav on Linux) instead of the user's data directory (~/.local/share/etesync-dav on Linux). Most users won't even notice the change, but we are happy to have finally fixed this legacy relic.
As usual, we would like to remind you that we rely on your feedback and contributions to make EteSync better. Do you have any suggestions or are experiencing any issues? Please send patches, report issues or just contact us.
Follow us on Mastodon, Twitter, Facebook, reddit or RSS for the latest updates and privacy-related content!