Add-on SDK 1.0b1 update: blocker bugs and e10s concerns

[Myk Melez]

Rocketeers!

Last last week and over the weekend, we identified some release blockers in documentation and in event handler parameters (which are inconsistent between the high-level modules). We have landed fixes for some of those, while others still need patches. The remaining work seems well-in-hand, however.

On the other hand, I'm growing increasingly concerned about our ability to promise API stability after e10s integration, given recent conversation in bug 582808 and a conversation I have since had with Atul. It doesn't seem like we fully understand the ramifications of separate addon processes on our process-spanning APIs, and some of the APIs that we think we have made e10s-compatible might not be after all.

I'm not yet sure what to do about that. Options include:

1. shipping the initial beta and then maintaining API stability by any means necessary;
2. shipping the initial beta but breaking API stability as needed;
3. delaying the initial beta until we've integrated e10s and fully understand its ramifications for our API design efforts.

Option 1 potentially means implementing asymmetric RPC mechanisms as described in bug 582808 and living with the unforeseen consequences of that untested approach to cross-process communication. It is the track we are currently on.

Option 2 requires changing what we mean by a "beta" of the Add-on SDK.

Option 3 requires diverting the release train we are currently on, either by delaying the release or by reversioning it to 0.10 (or 1.0a10) and rescheduling the beta.

I don't like option 2 very much. What's the point of a label like "beta" if its meaning can change so suddenly?

I don't like option 3 very much, either, since we're overdue for an initial beta of this product.

But I'm concerned that option 1 will saddle us with painful implementation and API issues that we will be forced to live with for a very long time.

I'll be ruminating on this question at length today, and any illuminating thoughts you have would be most welcome.

Cheers,
-myk

[Seth Wagoner]

All options seem about equally painful, I understand the conundrum.
Without knowing much about the details, I would put in a vote for
option 3, and with a re-versioned release rather than a delay of
unknown length.

The fewest developer gripes will probably come from option (1), but it
may well cost you momentum in the long term.

The most gripes will come if you go with (2), ship the beta and then
have to break some APIs, and arguably you'll get a few gripes
immediately just by admitting that you've redefined what beta means in
this context. Having said that, the number of significant changes for
add-on developers during the Firefox 4 "beta" phase have already given
some of us pretty low expectations in that regard.

I don't know a lot about the add-on convention, never having managed
to be in the bay area for one, but I am guessing most people serious
enough to go to it will make their decisions based on the real state
of play and won't care what the next version is actually called.

Arguably the best timing for announcing a beta is during add-on con
while the tech bloggers are paying more attention to add-ons, but is
that enough of a reason to go with (1) or (2) over (3)?

In any case, I don't envy you your decision. Good luck!

-- Seth.

> --
> You received this message because you are subscribed to the Google Groups
> "mozilla-labs-jetpack" group.
> To post to this group, send email to mozilla-la...@googlegroups.com.
> To unsubscribe from this group, send email to
> mozilla-labs-jet...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mozilla-labs-jetpack?hl=en.
>

--
Seth Wagoner
www.sethop.com
twitter.com/sethop

[Wes Kocher]

+1 for "release update soon, don't call it a beta"

[Myk Melez]

On 12/06/2010 04:49 PM, Seth Wagoner wrote:

Arguably the best timing for announcing a beta is during add-on con
while the tech bloggers are paying more attention to add-ons, but is
that enough of a reason to go with (1) or (2) over (3)?

No, it's better for the release to miss Add-on-Con than be released before it's ready! This is not a marketing- or date-driven release, and it mustn't be released before we think it's ready to go.

In any case, I don't envy you your decision. Good luck!

Thanks!

So, I did some more digging yesterday, and I talked to Benjamin and again to Atul this morning.

There are three options for communication between addon processes and chrome/content processes:

1. asynchronous message passing
2. blocking calls from addon -> chrome/content
3. asymmetric calls (blocking in addon, not blocking in chrome/content) à la bug 582808
   

Asymmetric calls are relatively untested and make it easy to create unexpected call patterns, and my primary concern has been around the possibility that we would need to make a number of such asymmetric calls to maintain API stability after e10s integration.

A secondary concern is that blocking calls might be problematic, as I was under the impression that Benjamin had once voiced concerns about them.

And a tertiary concern is that we will expose unexpected differences in the behavior of e10sified code that will require additional effort to work around (as Atul discovered when e10sifying the `xhr` module).

However, upon further review, I don't think we will need to make many (or possibly any) asymmetric calls after all, as most of our APIs are either explicitly asynchronous (and thus can use asynchronous message passing) or call synchronous functions in chrome/content (and thus can use blocking calls).

And Benjamin says blocking calls are fine, with the caveat that blocking calls can generate messages to the addon process that cause unexpected reentry into that process or trigger an infinite loop (such as a selection listener that sets the selection, again triggering the selection listener). But that's no different from code in a single process.

I still have that tertiary concern about unexpected differences in behavior. But I think that our Add-on Kit APIs are high-level enough that we'll be relatively ok there and able to handle those differences as they arise (the low-level APIs in API Utils are another matter, but we aren't promising their stability yet).

Thus I think we are indeed ready to ship a beta release whose high-level APIs are relatively stable and unlikely to change between the beta and the final release.

I do expect us to continue to enhance these APIs (and add new ones) as we learn more about the best ways to design APIs that cross processes, and we may eventually deprecate some of them in favor of newer ones with better semantics. But I don't think we're likely to need to break them at this point.

-myk