Re: New approach to activities/intents

Dimitri Glazkov wrote:
> I thought about this a bit and realized that we first need to have a 
> common criteria to evaluate whether we even need something like Tubes. 
> That should be done before we get into mechanics of the solution. I 
> apologize for jumping the gun. And I apologize even more to poor op 
> whose conversation we hijacked.
>
> So I came up with the following Capability Availability Success Criteria:
>
> Given any capability on a modern computing device and a developer who 
> wants to use it, what is a) the acceptable delay between when this 
> capability becomes available on the web platform vs. first being 
> available on a native platform, and b) the likelihood that this 
> capability will ever be available on the web platform.
>
> If we're aiming at "years, not months", and "60-80%", then we're 
> already successful.
>
> If we're hoping to hit "weeks, not months" and "100%", we need 
> something like Tubes.
>
> If it's something in between, maybe there are other options.

There are definitely other options. I think you've backed yourself into 
a dialectical corner. MessagePorts are not the primitive droids we're 
looking for! For one, JS SIMD cannot and should not use them. Even 
witha  sync-on-this-async-API-call general API, they are not the right 
droid.

I see roc has replied (we are not communicating via back-channels) so 
I'll stop here.

The actor model is beautiful and in part true, but it's not workers or 
MessagePorts, and it's not the right droid. Even if we add actors to the 
web platform, we will need to make particular, non-actor, synchronous 
API additions. These require careful design and (multiple browser) 
implementation with web developer feedback validation. Sorry, no easy 
answers. I do not think we need weeks not months, in any event (as noted 
vs. native stacks). We need intentional design with user (web dev) testing.

/be

Received on Wednesday, 12 November 2014 00:40:02 UTC