[webkit-dev] SharedScript/Worker and multiprocess browsers

[Jeremy Orlow]

On Mon, Nov 30, 2009 at 5:05 PM, Oliver Hunt <oliver at apple.com> wrote:

>
> Sorry, I think you misunderstand.  The way Chrome processes are divided is
> an implementation detail, but it is an important one.  I think it is folly
> to ignore it when designing web APIs.  We'll likely *never* implement APIs
> that involve cross-process, synchronous script evaluation.  We have some
> experience with that in supporting plugins, and I can tell you that I do not
> favor it: not just because of implementation complexity but also because of
> the performance impact it entails.
>
>
> It is wrong to design an API based on architectural decisions of your
> existing browser -- you should be making decisions based on what the
> developers actually need.  Being hard for the browser to implement is a
> secondary concern next to being hard for the end developer to use.
>
>   The issue being that in regular day to day use such a browser could end
>> up producing behaviour inconsistent with behaviour that of browsers that
>> actually did provide a single shared context -- in effect all users of
>> Global/SharedScript would have to assume that their Global/SharedScript
>> context was not in fact shared.
>>
>
> This is true, but I don't think it is a big deal.  Processes are roughly
> divided up into browsing units.  You start a new browsing unit by opening a
> new tab and navigating it.  By doing so, you are creating a separate world
> that cannot see other worlds.  SharedWorkers (as well as cookies and other
> storage mechanisms) provide a bridge between these worlds, but window.open
> and SharedScripts do not (b/c of the script connection they imply).
>
>
>
> I have a (simple) question: If Global/SharedScript is not guaranteed to be
> either Global or Shared, what is it trying to accomplish?  It's not possible
> for any developer to use them for shared state as they can't guarantee that
> a normal user, doing normal things, is not going to end up with distinct
> instances of this "shared" state.
>

Please look at the use cases in the spec.  They're pretty much all an
optimization to cut down on resource utilization and load times by sharing
more state.

As a side note, I would expect that many SharedScript users would also use
SharedWorkers for a lot of the non-UI logic including storage and network.

Also note that the possibility of having multiple SharedScript instances
within one browser is pretty much the same as the possibility of the user
having multiple browsers open on the same computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/fbddbeba/attachment.html>