On 1/17/2012 7:30 AM, Benjamin Smedberg wrote:
> This post was prompted by the thread "Why do we keep revising intervace
> ids?" in mozilla.dev.platform, and Asa's reply which suggests that we
> reconsider our current policy of breaking (requiring a recompile) of
> binary components in each 6-week cycle. I thought that before we got
> into the details of our solution we should define the problem space.
>
> == Purpose ==
>
> Loadable XPCOM components allow developers of both applications and
> extensions access to the following basic functions:
>
> * Adding new functionality to the platform available via our XPCOM
> object framework.
> * Extending existing functionality of the platform, for example adding a
> new protocol handler.
> * Replacing core functionality of existing components/services.
I have started thinking of our platform as being like an OS and looking
for inspiration on APIs and architectures in OSs. Along those lines,
#1/#2 above could be done as either libraries or device drivers,
depending on how deeply they are integrated with the platform. Either
way, an OS would try to provide a pretty stable API (evolution over the
years, not the months). For #3, the main example that comes to mind is
complete UI replacements (explorer.exe or window managers), but it seems
replacing core features in a stable way is not done much and may not be
very practical--just producing a custom version of the platform seems
more likely.
But before thinking too hard about that, what is the long-term future of
binary extensions? roc recently predicted that NPAPI plugins will go
away, meaning we should worry only about user experience issues for
existing plugins:
http://robert.ocallahan.org/2011/11/end-of-plugins.html
I'm not sure if the comment about Windows 8 applies only to NPAPI
plugins, or other binary extensions too. I think there are valid use
cases for binary extensions, but if we don't expect them to be allowed
by the underlying platform or to continue to be used, then it wouldn't
make much sense to work on them.
If we are going to continue with binary extensions, I'd like to see us
get well-designed, stable APIs. It would take a while to get there,
though, and there is still the question about whether add-on developers
would actually use the new APIs.
> == Possible Alternatives ==
>
> There are few possible alternatives for what we could do to make using
> binary components easier or harder:
>
> A. Change nothing, leave the status quo as-is. Extensions which use
> binary components and are not recompiled every 6 weeks will "break", but
> they at least have the opportunity to do cool stuff . Users will
> continue to be vulnerable to Oracle-type crashes.
We know roughly how this looks. :-)
> B. Make no technical changes, but disallow binary components in release
> extensions on AMO. We may allow binary components in beta or
> experimental addons, with the understanding that these would need to be
> updated for each release.
This option is hard for me to understand. It seems to be essentially a
ban on binary components, except in prototyping. Is it really that much
easier to prototype as a binary extension? And what does the prototype
lead to, if it can't be shipped? A patch to the platform? A non-AMO addon?
> C. (copied from Asa's post) Only change interfaces every 3rd release (or
> something like that). This would mean that extensions which use C++
> components would need to compile less frequently. Users would still be
> exposed to Oracle-type issues, but less frequently.
This seems really disruptive to development, especially if it applies to
all interfaces. Is there a subset of the interfaces that is useful to
add-on developers that we could keep stable?
> D. Stop loading binary components from extensions. Continue exporting
> the XPCOM functions so that application authors can continue to use
> them. Users might still be exposed to Oracle-type issues.
> E. Stop loading binary components completely: compile Firefox as a
> static binary and stop exporting the XPCOM functions completely.
These two make sense if we do decide that binary components are going away.
> == bsmedberg's Opinion ==
>
> I see binary components as a useful tool in very specific circumstances.
> Primarily, they are a good way to prototype and experiment with new
> features which require mucking about with Mozilla internals. But I tend
> to think that we should discourage their use in any production
> environment, including perhaps disallowing them on AMO. I tend to think
> we should consider option "B".
Personally, I know way too little about the ecosystem of add-ons with
binary components, what they do, and what other kinds of implementations
they could use to be able to make a decision. It seems like a really
deep problem.
But the core issue that your options revolve around does seem to be: do
we want to keep binary components at all? I see 3 main options:
1. Deprecate and eventually remove binary components, on the grounds
that they are hard to support and won't be allowed on all platforms.
(Also, we could later revive them in some new form if we wanted.)
Besides the obvious "life gets easier", I'm not sure what the effects
are--especially, how do vendors of add-ons with binary components react?
(And is this the path MS is taking?)
2. Do binary components right: provide stable APIs and QA binary
components. It's expensive and doesn't solve anything in the immediate
future, but it does create a good, stable environment for binary
components (if it works). It seems like this is what Google is going for
with PPAPI and NaCl.
3. Bounce along as we are: unstable binary components. This is OK for
now but I don't see it as a sound long-term plan.
Dave