-
-
Notifications
You must be signed in to change notification settings - Fork 56
Roadmap
Thunderbird 68.x was a devastating hit on this addon. And made the inevitable clear, "classic" and legacy addons are gone and won't come back.
Luckily the Plan B - porting the add-on to an Electron based standalone app - worked out quite good and the app has shown to be very stable.
Electron was one of the new kids on the block and the new rising star in the JavaScript universe. It is now widely used in various application. You have most likely used Electron based applications without knowing it.
Technically it is a stripped down Chromium browser bundled with Node.js. It supports complex JavaScript APIs with almost no limitation, virtually the sky is the limit. Quite the opposite of WebExtensions.
All basic functionally is ported from the classic Thunderbird add-on. Parity with the legacy addon has been reached. And it is the development target for new features.
Back in 2019/2020 it looked as if a Thunderbird add-on would be dead. Porting to a WebExtension was not possible because of a very silly WebExtension limitation which was posed only for strange political reasons. But unexpected things happen time by time. The Thunderbird guys decided to removed this limitation and now "WebExtension Experiments" are available in in release builds and not only in developer or nightly builds.
This change brings back lots of the flexibility of classic legacy add-ons and made porting the app back to a WebExtension possible.
But there are still lots of ifs and whens. Especially the future of "WebExtension Experiments" is still very undefined. They are announced to be turned of somewhere in the future. But this is honestly getting more and more unlikely as too many WebExtension depend upon them. But in case the experiments go, the add-on will be also dead.
The WebExtension is far way from parity with the old add-on or the application and will never reach parity.
Moving to Electron meant all of the UI was converted to HTML5 and vanilla JavaScript. Thus all of the UI runs perfectly inside a Web browser. Only the communication with the Sieve Server can not be implemented, because Browser offer no mechanisms to create non http connections.
So I started experimenting, wrote a small proxy which wraps a sieve connection into a websocket connection. This allows the Sieve Client to be run inside a browser. The first version is released but it is still in a very early stage.
The manage sieve core implements the complete RFC 5804 (A Protocol for Remotely Managing Sieve Scripts) and the code base is rather stable. All common SASL (Simple Authentication and Security Layer) algorithms are supported, with one exception GSSAPI (Generic Security Services Application Program Interface).
The core has proven to be very stable. Porting from Thunderbird to Electron required, other than expected, only minimal changes. So there is not much left to do here.
The graphical sieve editor dramatically improved when the next generation parser landed. And is also in a stable state and works well. It has still minor issues which need to be addressed, but nothing too important.
Refer to capabilities for a complete list of all implemented sieve and manage sieve features.