Re: Getting offline right and fast (was: Volunteers needed to work on action plans)

On Tuesday, May 14, 2013, Dominique Hazael-Massieux wrote:

> Hi Robin, Jonas, Alex,
>
> Le mardi 07 mai 2013 à 10:21 +0200, Dominique Hazael-Massieux a écrit :
> > > Do we actually need an action plan? The way I see it, the one critical
> > > item here is to ship NavCon. So my proposed action plan would be:
> > >
> > > • Alex has enough bandwidth to shepherd NavCon: let him and the crew
> > > around it keep going;
>

Navigation Controller is my day job at this point. Indeed, I had a
productive meeting with Jonas et. al. last week in San Francisco on this
very topic, the results of which are finding their way into the github repo
right now.


> > > • If not: jump in and help.
> >
> > That seems a bit too narrowly focused on specification development; the
> > type of additional work we could propose would include to help e.g.
> > gather early developers feedback, prototype some of the use cases on top
> > of NavCon, do a dev rel campaign around the feature to expose it as
> > broadly as possible, etc.
>

One of the Chrome team's goals here is to get this system into developer's
hands as soon as reasonably possible. That includes prototyping via
extensions as well as early implementations behind flags. Jake (cc'd) has
committed to helping to turn our use-cases into code examples as a way of
testing the system. We have also signed up at least one internal team to
refactor their system on top of the early implementation.

As you know, this *is* a big design space and there *are* thorny issues to
be worked out but the goal here is* *explicitly not to drag an un-ready
design out into the town square to be beaten by anyone with a passing
opinion. Scenario-solving design (as we witnessed in AppCache) is driven by
pain ("I'll give you any feature you want, just stop yelling at me!"). This
is a terrible crouch to be designing from.


> > We could also invest resources in setting up early test suites (to help
> > implementations convergence early on); and I'm sure there are more ideas
> > in this space — the point of drafting an action plan would be to list
> > these ideas and get feedback from the relevant players on their
> > usefulness/importance :)
>
> I'm still very much interested in getting your ideas and feedback on my
> ideas on what we could to help move faster on getting a better solution
> out for offline use cases; pretty please?
>

I feel for you. You want a public list of "look! those are the things we're
going to fix!"...some sort of a big target to run at. But that's not how
good design works.

Good designs look at a set of problems (which we *have* done in depth:
https://github.com/slightlyoff/NavigationController/tree/master/examples),
the pieces on the board, and attempt to understand where the viable
permutations lie. Even better, then, to expose the pieces so that others
can re-compose them should you get it wrong. This is what we mean by
"primitives". But characterizing a class of architectures from use-cases is
more important than adding some set of arbitrary constraints -- a process
which can easily over-constrain a design.

Here's an example for you: this isn't about offline *at all*. It's about
enabling systems to marry requests with responses, sometimes from a cache.
And it's about partially-cached graphs of application data. The nexus of
those two points is a design embodied by many application architectures
today, including online apps, and which is poorly supported by the platform.

That's the sort of thing you get out of deep investigation: not a list of
things you'll solve, but a better understanding of what the problem is.
It's not clear that the use-case gathering effort that's under way here is
adding much.

Regards