As I mentioned in Dietrich's "new features, bitrot & killswitches"
thread, I'm interested in:
1) Making it easier for add-on developers and would-be add-on developers
to get started by providing add-ons they can build from, both trivial
(to fork from) and complex (as examples of how to do something more
complex).
2) Biasing our apps to be add-on friendly by making sure the developers
writing the app know the pain of writing add-ons for the app.
In the world of email, there are a multitude of potential extension
points. Many of those are not something that we can do as a first step,
although I'd like to get there some day. And we can't do them all at
once. But we can do some of them.
So what'd be great is if those interested in writing an e-mail add-on or
interested in using an e-mail add-on could go to
https://etherpad.mozilla.org/fxos-email-addon-hook-ideas and skim and
maybe contribute some ideas. My goal is to pick a few small/simple
suggestions and implement them with room for improvement. The trick is
that other people fork them and improve them. And then we iterate on
adding more extension points and more examples.
Andrew
PS Implementation Note: I'm assuming that CSP means that it will
effectively be impossible for the email backend that lives in the worker
to dynamically require() code from any add-ons. This will initially
limit things since it will require all activity to occur on the main
page. But in the long run, I think a wide-usage extension model would
want to sandbox the extensions anyways, in which case we would use a
separate origin where we entirely rely on message-passing anyways.