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