[webkit-dev] Multiprocess networking in WebKit

[Michael Nordman]

About MemCache considerations, you list these options...
* Do not share storage
* Share storage but hits in remote caches are asynchronous
* Share storage and all cache hits are serviced synchronously

Is there a fourth option?
* Share storage and all cache hits are async in all cases (the resulting
handle is returned asyncly, but the data is then directly addressable).

And then maybe a fifth two-tiered option that builds on the above to get to
something more satisfying?
* Shared storage is accessible asyncly at the level of ResourceHandle (that
fourth option).
* Local handles to shared resources are accessible syncly at the level of
todays MemCache, where the local memcache gets populated with handles to
resources in shared storage.

I'm merrily ignoring how decoded data is also associated with
CacheResources (and how it can mutate depending on attributes of the
Document for which it was most recently decoded).





On Mon, Dec 3, 2012 at 4:16 PM, Adam Barth <abarth at webkit.org> wrote:

> There's been a somewhat fragmented discussion across webkit-dev and
> various bugs about how we ought to approach multiprocess networking in
> WebKit.  In an attempt to organize my thoughts, I wrote up a short
> design document that compares various approaches:
>
>
> https://docs.google.com/document/d/1ihpwbiG_EDirnLibkkglEtyFoEEcf7t9XNAn8JD4fQY/edit
>
> My hope is that this document will be useful as a starting point for
> discussion.  If other folks have written similar documents, those
> might make valuable contributions to the discussion as well.
>
> I welcome your feedback, either via comments in the document or via
> this email thread.
>
> Thanks,
> Adam
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20121203/4ae74a5c/attachment.html>