[jetpack] 0.4 and 0.5 development plans

[Myk Melez]

Hi all,

Based on our brainstorming session in this week's Jetpack project meeting, the list of things that missed 0.3, some investigation of the work already in flight, and some thinking about long term strategy and goals, I put together a draft 0.4 development plan and an even draftier 0.5 development plan.

I also set up a page for projects that don't easily fit into one of these plans, either because they are larger, longer-term efforts that span multiple cycles or because it's not yet clear when to work on them.

And I took a first stab at prioritizing deliverables within the given milestones. The priorities are partly based on overall project goals and partly on individual workload.

Specifically, regarding overall project goals, you'll notice that the APIs are all P1s (highest priority), since landing the initial set of APIs is key to getting developers to try out the platform and give us the feedback we need to iterate on the APIs until they meet developers' needs.

And regarding individual workload, I tried to make sure that multiple deliverables assigned to a single person are a mix of priorities, so it's clear how to order and prioritize the work.

Keep in mind that a development plan is not a comprehensive list of everything that's going to happen in a development cycle, it's just the set of important items that define the release and whose resolution we should prioritize. So just because a bug/enhancement isn't on the list, that doesn't mean you can't fix/implement it!

There are some items from the brainstorm that aren't on any of the pages. Here's my thinking on those:

• directory of community-created packages: this seems more of a project than a specific deliverable, but it's also something that fits into FlightDeck (whose dev plans I'm still in the process of drafting); still thinking about where to slot this in.
  
  
• JS catchalls: not sure where to slot this in yet; if Simple Storage depends on it, then that makes it a high priority for 0.4. If Simple Storage can live without it for now, however, then it's not urgent. Need more info here.
  
  
• content exposure module: I don't understand this well enough to know where it should live; I'll powwow with Brian to learn more about this.
  
  
• factoring out shared code: I tend to agree with adw that this should be a standard part of the develop/review process rather than something we schedule as part of release cycles; nevertheless, I'm not averse to doing a refactoring sprint (in fact, it sounds like fun!). And it's also great to file/fix specific instances as we encounter them, as we do with lots of other bugs and enhancements.
  
  
• toolbar button API: the Single UI Element API should satisfy this use case, although we can circle back around if it seems like it doesn't once we implement it.

Take a look at the plans and project page, and let me know what you think!

    https://wiki.mozilla.org/Labs/Jetpack/SDK/0.4
    https://wiki.mozilla.org/Labs/Jetpack/SDK/0.5
    https://wiki.mozilla.org/Labs/Jetpack/Projects

-myk

--
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.

[Drew]

> * JS catchalls: not sure where to slot this in yet; if Simple

> Storage depends on it, then that makes it a high priority for 0.4.
> If Simple Storage can live without it for now, however, then it's
> not urgent. Need more info here.

JS catchalls could potentially optimize the simple storage
implementation, to make a long story short.

The simple storage JEP proposes an API that's really easy to use:
Storage is just a persistent JS object. But without a way to determine
which parts of that object's graph are in use, there's no choice but to
keep the entire graph in memory. Plus, we have to write out the entire
graph even for parts that haven't changed. If your extension saves the
Web using simple storage -- not to mention if you have 20 such
extensions installed -- not good.

With catchalls we're potentially able to ignore the parts not being
used. So when your extension refers to storage.foo, we intercept the
get, check if foo is in memory, and load it if not. And when you set
storage.foo, we write out only that new value, rather than writing out
the entire graph. (I poked around Gecko's DOM Storage implementation,
and from what I could tell that's basically how it works. Of course it
has full access to Spidermonkey, unlike us.)

Without catchalls, I think it would be wise to cap an extension's simple
storage to some small capacity, and if possible to also simultaneously
introduce a complementary API capable of handling more data.

What do people think?

> * factoring out shared code: I tend to agree with adw that this

> should be a standard part of the develop/review process rather
> than something we schedule as part of release cycles;
> nevertheless, I'm not averse to doing a refactoring sprint (in
> fact, it sounds like fun!).

Yeah, sorry Atul, I shouldn't have been critical about that while we
were brainstorming. A refactoring sprint sounds valuable to me too.

Drew

On 4/29/10 11:21 AM, Myk Melez wrote:
> Hi all,
>
> Based on our brainstorming session in this week's Jetpack project
> meeting, the list of things that missed 0.3, some investigation of the
> work already in flight, and some thinking about long term strategy and
> goals, I put together a draft 0.4 development plan

> <https://wiki.mozilla.org/Labs/Jetpack/SDK/0.4> and an even draftier 0.5
> development plan <https://wiki.mozilla.org/Labs/Jetpack/SDK/0.5>.

>
> I also set up a page for projects

> <https://wiki.mozilla.org/Labs/Jetpack/Projects> that don't easily fit

> into one of these plans, either because they are larger, longer-term
> efforts that span multiple cycles or because it's not yet clear when to
> work on them.
>
> And I took a first stab at prioritizing deliverables within the given
> milestones. The priorities are partly based on overall project goals and
> partly on individual workload.
>
> Specifically, regarding overall project goals, you'll notice that the
> APIs are all P1s (highest priority), since landing the initial set of
> APIs is key to getting developers to try out the platform and give us
> the feedback we need to iterate on the APIs until they meet developers'
> needs.
>
> And regarding individual workload, I tried to make sure that multiple
> deliverables assigned to a single person are a mix of priorities, so
> it's clear how to order and prioritize the work.
>
> Keep in mind that a development plan is not a comprehensive list of
> everything that's going to happen in a development cycle, it's just the
> set of important items that define the release and whose resolution we
> should prioritize. So just because a bug/enhancement isn't on the list,
> that doesn't mean you can't fix/implement it!
>
> There are some items from the brainstorm that aren't on any of the
> pages. Here's my thinking on those:
>

> * directory of community-created packages: this seems more of a

> project than a specific deliverable, but it's also something that
> fits into FlightDeck (whose dev plans I'm still in the process of
> drafting); still thinking about where to slot this in.
>

> * JS catchalls: not sure where to slot this in yet; if Simple

> Storage depends on it, then that makes it a high priority for 0.4.
> If Simple Storage can live without it for now, however, then it's
> not urgent. Need more info here.
>

> * content exposure module: I don't understand this well enough to

> know where it should live; I'll powwow with Brian to learn more
> about this.
>

> * factoring out shared code: I tend to agree with adw that this

> should be a standard part of the develop/review process rather
> than something we schedule as part of release cycles;
> nevertheless, I'm not averse to doing a refactoring sprint (in
> fact, it sounds like fun!). And it's also great to file/fix
> specific instances as we encounter them, as we do with lots of
> other bugs and enhancements.
>

> * toolbar button API: the Single UI Element API should satisfy this

[Brian Warner]

On 4/30/10 8:01 AM, Drew wrote:
>
> The simple storage JEP proposes an API that's really easy to use:
> Storage is just a persistent JS object. But without a way to determine
> which parts of that object's graph are in use, there's no choice but to
> keep the entire graph in memory. Plus, we have to write out the entire
> graph even for parts that haven't changed. If your extension saves the
> Web using simple storage -- not to mention if you have 20 such
> extensions installed -- not good.

Is there anything we can do to improve the experience when somebody
*does* accidentally save the entire web? I've written object-graph
traversal systems before, and when I did something wrong (forgot about a
reference to some big chunk of stuff that wasn't supposed to be
serialized), I usually discovered the problem because of serialization
errors. In those systems, you had to explicitly mark the objects/classes
that were serializable, and you got an error when the graph traversal
ran into something that wasn't marked.

I can't immediately think of a good way to do this for JS.. maybe only
serialize primitive types? The big problem is silent failures: if the
developer saves more than they meant to, but everything still works,
they may never find the error. Perhaps a tool or a control panel to dump
the add-on's saved state as text, so you can look at it and see if
you've got more (or less) data than you expect?

Oh, maybe even build it into the API:

console.log("state is " + require("storage").dump_as_text())

> Without catchalls, I think it would be wise to cap an extension's simple
> storage to some small capacity, and if possible to also simultaneously
> introduce a complementary API capable of handling more data.
>
> What do people think?

Maybe provide the get/set API now, and then the property-based API later
when we get catchall support?:

var data = require("storage").get(key);
require("storage").put(key, newdata);

var storage = require("storage").storage;
storage.key = value;
data = storage.key;


cheers,
-Brian

[Drew]

> errors. In those systems, you had to explicitly mark the objects/classes
> that were serializable, and you got an error when the graph traversal
> ran into something that wasn't marked.

> I can't immediately think of a good way to do this for JS.. maybe only
> serialize primitive types?

We could do something similar for JS, but in the context of simple
storage, which is designed to maximize ease of use, I'd pick a simple
scheme of just serializing all primitives in the graph reachable from
the root. In fact that's what the JEP specifies will happen, regardless
of whether the implementation uses catchalls.

> The big problem is silent failures: if the
> developer saves more than they meant to, but everything still works,
> they may never find the error.

Good point.

> Perhaps a tool or a control panel to dump
> the add-on's saved state as text, so you can look at it and see if
> you've got more (or less) data than you expect?

Awhile ago Myk and I discussed quotas in simple storage, and my plan was
to let the user define a callback on the module that's called when they
go over quota. It could be extended to notify when arbitrary byte
lengths are passed, maybe other events like when the object tree exceeds
N levels. That wouldn't catch all oops-I-saved-too-much errors of
course, but maybe it's a start?

> Maybe provide the get/set API now, and then the property-based API later
> when we get catchall support?:

Yeah, that's a compromise, but I'm reluctant to fork the API like that
and would rather just start off with a not-so-simple storage that's more
robust.

Drew