Why resurrect STEEL, the API? I think all features in STEEL had replacements (those used by TB had and we received no complaints from addons). Shouldn't we just expose APIs via Webextension system that are not otherwise available? ______________________________________________________________ > Od: Philipp Kewisch <kewisch@thunderbird.net> > Komu: Ben Bucksch <ben.bucksch@beonex.com>, maildev@lists.thunderbird.net > Dátum: 04.04.2018 13:18 > Predmet: Re: [Maildev] The end of non-restartless add-ons - The future of > >Yes, of course. There are definitely some APIs that would qualify for a >basic set that we should be working on, and if we can also engage >developers of add-ons that use it to support us that would allow for >great synergy. Thanks for the reminder on STEEL, I agree it is a good >starting point. > >Philipp > >On 4/4/18 12:11 PM, Ben Bucksch wrote: >> I think the TB project should add a good base set of APIs. >> >> A good starting point for APIs might be STEEL >> <https://wiki.mozilla.org/User:Jminta/Steel> (not the implementation, >> but the API signatures, more or less). >> >> >> Philipp Kewisch wrote on 30.03.18 19:34: >>> This is along the lines of what I have been thinking as well. My idea was to allow WebExtension Experiments on release in Thunderbird, and encourage add-on authors to adapt their add-ons to mainly be a WebExtension. For the missing functionality, they would write experiment apis that can use xpcom, using a set of guidelines we prepare. >>> >>> The experiment apis should be submitted as a PR to a webextension-experiments repo on our github account, which we can then give feedback on, and accept those that follow our guidelines and have potential. We can take the good ones and integrate them into Thunderbird >>> >>> We need to be careful to not allow EVERYTHING as an api, otherwise we’ll never be able to do any refactoring without breaking add-ons, and of course there is the expectancy that any api we accept will be maintained going forward, which requires developer time. It also means we will need to limit the UI exposed to add-ons, otherwise we spend a lot of effort maintaining apis that target UI we might want to change or remove. >>> >>> The docs on wx experiments are a bit out of date, I’m looking to create a sample api for FileLink soon that will demonstrate how it works.

Ben was saying we should not resurrect the API, but instead use the method signatures as inspiration for new, WebExtension-style APIs. Philipp On 4/4/18 2:06 PM, Aceman wrote: > Why resurrect STEEL, the API? > > I think all features in STEEL had replacements (those used by TB had and we received no complaints from addons). Shouldn't we just expose APIs via Webextension system that are not otherwise available? > > ______________________________________________________________ >> Od: Philipp Kewisch <kewisch@thunderbird.net> >> Komu: Ben Bucksch <ben.bucksch@beonex.com>, maildev@lists.thunderbird.net >> Dátum: 04.04.2018 13:18 >> Predmet: Re: [Maildev] The end of non-restartless add-ons - The future of >> >> Yes, of course. There are definitely some APIs that would qualify for a >> basic set that we should be working on, and if we can also engage >> developers of add-ons that use it to support us that would allow for >> great synergy. Thanks for the reminder on STEEL, I agree it is a good >> starting point. >> >> Philipp >> >> On 4/4/18 12:11 PM, Ben Bucksch wrote: >>> I think the TB project should add a good base set of APIs. >>> >>> A good starting point for APIs might be STEEL >>> <https://wiki.mozilla.org/User:Jminta/Steel> (not the implementation, >>> but the API signatures, more or less). >>> >>> >>> Philipp Kewisch wrote on 30.03.18 19:34: >>>> This is along the lines of what I have been thinking as well. My idea was to allow WebExtension Experiments on release in Thunderbird, and encourage add-on authors to adapt their add-ons to mainly be a WebExtension. For the missing functionality, they would write experiment apis that can use xpcom, using a set of guidelines we prepare. >>>> >>>> The experiment apis should be submitted as a PR to a webextension-experiments repo on our github account, which we can then give feedback on, and accept those that follow our guidelines and have potential. We can take the good ones and integrate them into Thunderbird >>>> >>>> We need to be careful to not allow EVERYTHING as an api, otherwise we’ll never be able to do any refactoring without breaking add-ons, and of course there is the expectancy that any api we accept will be maintained going forward, which requires developer time. It also means we will need to limit the UI exposed to add-ons, otherwise we spend a lot of effort maintaining apis that target UI we might want to change or remove. >>>> >>>> The docs on wx experiments are a bit out of date, I’m looking to create a sample api for FileLink soon that will demonstrate how it works.

Yes, exactly. Inspiration, not implementation. STEEL has a high-level approach, higher than the IDL of our internal APIs. I think it's the right kind of abstraction, the same high level APIs as web extensions use. Ben Philipp Kewisch wrote on 04.04.18 14:24: > Ben was saying we should not resurrect the API, but instead use the > method signatures as inspiration for new, WebExtension-style APIs. > > Philipp > > On 4/4/18 2:06 PM, Aceman wrote: >> Why resurrect STEEL, the API? >> >> I think all features in STEEL had replacements (those used by TB had and we received no complaints from addons). Shouldn't we just expose APIs via Webextension system that are not otherwise available? >> >> ______________________________________________________________ >>> Od: Philipp Kewisch <kewisch@thunderbird.net> >>> Komu: Ben Bucksch <ben.bucksch@beonex.com>, maildev@lists.thunderbird.net >>> Dátum: 04.04.2018 13:18 >>> Predmet: Re: [Maildev] The end of non-restartless add-ons - The future of >>> >>> Yes, of course. There are definitely some APIs that would qualify for a >>> basic set that we should be working on, and if we can also engage >>> developers of add-ons that use it to support us that would allow for >>> great synergy. Thanks for the reminder on STEEL, I agree it is a good >>> starting point. >>> >>> Philipp >>> >>> On 4/4/18 12:11 PM, Ben Bucksch wrote: >>>> I think the TB project should add a good base set of APIs. >>>> >>>> A good starting point for APIs might be STEEL >>>> <https://wiki.mozilla.org/User:Jminta/Steel> (not the implementation, >>>> but the API signatures, more or less). >>>> >>>> >>>> Philipp Kewisch wrote on 30.03.18 19:34: >>>>> This is along the lines of what I have been thinking as well. My idea was to allow WebExtension Experiments on release in Thunderbird, and encourage add-on authors to adapt their add-ons to mainly be a WebExtension. For the missing functionality, they would write experiment apis that can use xpcom, using a set of guidelines we prepare. >>>>> >>>>> The experiment apis should be submitted as a PR to a webextension-experiments repo on our github account, which we can then give feedback on, and accept those that follow our guidelines and have potential. We can take the good ones and integrate them into Thunderbird >>>>> >>>>> We need to be careful to not allow EVERYTHING as an api, otherwise we’ll never be able to do any refactoring without breaking add-ons, and of course there is the expectancy that any api we accept will be maintained going forward, which requires developer time. It also means we will need to limit the UI exposed to add-ons, otherwise we spend a lot of effort maintaining apis that target UI we might want to change or remove. >>>>> >>>>> The docs on wx experiments are a bit out of date, I’m looking to create a sample api for FileLink soon that will demonstrate how it works. > >