On Wed, Sep 16, 2009 at 4:05 PM, Michael Nordman <span dir="ltr"><<a href="mailto:michaeln@google.com">michaeln@google.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div><div></div><div class="h5">On Wed, Sep 16, 2009 at 3:30 PM, Jeremy Orlow <span dir="ltr"><<a href="mailto:jorlow@chromium.org" target="_blank">jorlow@chromium.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>On Wed, Sep 16, 2009 at 3:21 PM, Robert O'Callahan <span dir="ltr"><<a href="mailto:robert@ocallahan.org" target="_blank">robert@ocallahan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Thu, Sep 17, 2009 at 9:56 AM, Jeremy Orlow <span dir="ltr"><<a href="mailto:jorlow@chromium.org" target="_blank">jorlow@chromium.org</a>></span> wrote:<br></div><div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div class="gmail_quote"><div><div></div>1) Create a LocalStorage like API that can only be accessed in an async way via pages (kind of like WebDatabase).</div><div><br></div><div>2) Remove any atomicity/consistency guarantees from synchronous LocalStorage access within pages (like IE8 currently does) and add an async interface for when pages do need atomicity/consistency.</div>
<div><br></div><div>3) Come up with a completely different storage API that all the browser vendors are willing to implement that only allows Async access from within pages. WebSimpleDatabase might be a good starting point for this.</div>
</div></blockquote><div> </div></div><div>4) Create WorkerStorage so that shared workers have exclusive, synchronous access to their own persistent storage via an API compatible with LocalStorage.<br></div></div></blockquote>
<div><br></div></div><div>Ah yes. That is also an option.</div><div><br></div><div>And, now that I think about it (combined with Jonas' last point) I think it might be the best option since it has a very low implementation cost, it keeps the very simple API, and solves the primary problem of not blocking pages' event loops.</div>
</div></blockquote><div><br></div></div></div><div>But it fails to solve the problem of a providing a shared storage repository for the applications use, which at least to me is the real primary goal.</div></div></blockquote>
<div><br></div><div>Is it? Can you provide some use cases? :-)</div><div><br></div><div>As I stated, my conversations with developers led me to believe having access to storage within workers is most important and that having shared memory between pages and workers would make things easier on some of them. In other words, from my talks, it's a secondary goal.</div>
<div><br></div><div><br></div><div>On Wed, Sep 16, 2009 at 3:57 PM, Jonas Sicking <span dir="ltr"><jonas@sicking.cc></span> wrote:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<div><div></div><div>On Wed, Sep 16, 2009 at 3:36 PM, Jeremy Orlow <<a href="mailto:jorlow@chromium.org" target="_blank">jorlow@chromium.org</a>> wrote:<br>> Code wise, what Robert suggested is MUCH simpler. Almost for free in<br>
> WebKit. Creating an asynchronous access method and exposing this in the<br>> page is much more complex. It also defeats the main purpose of LocalStorage<br>> (which is to be a simple, light weight way to store data).<br>
<br></div></div>The only difference between Roberts and my suggestion is that I'm also<br>adding a asynch accessor in the window. That doesn't seem to make it<br>"MUCH simpler", or am I missing something?<br>
</blockquote><div><br></div><div>Well, doing just a sync interface is "MUCH simpler", but I suppose there's no reason not to add both to the spec. To be clear, though, adding the sync interface to workers would be a much higher priority for me than the async interface. Enough so that there's a chance we'd ship a version of Chrome that did not yet implement the async interface. That seems OK to me, though.</div>
<div> </div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
I do agree that some of the additional optional<br>multiple-differently-named storage area does add additional<br>complexity, and maybe we should defer that to something like the<br>WebSimpleStorage spec.<br><div><br>> I certainly agree that having some shared memory format between workers and<br>
> pages would be good, and there's some use cases which would<br>> certainly benefit, but most of the developers I've talked to so far were<br>> mostly concerned about having _some_ form of storage and the shared memory<br>
> aspects were more nice to have.<br><br></div>What would the specifics of a worker-only storage be? Can multiple<br>different workers access it? (In which case they need to be protected<br>by a mutex). Is there one storage per worker URL? Or do all workers<br>
from a particular domain share the same workerStorage?<br><br>I'm also wondering what the use-cases for a worker-only storage is?<br></blockquote><div><br></div><div>The use cases all revolve around having a backend in a worker that handles offline and/or caching. It could either feed its data to the page via messages or shared memory. The former requires at least worker-only and the latter requires storage shared between the worker and the page. The latter is technically an optimization, but I agree that it's a fairly major one.</div>
<div><br></div><div>J</div></div></div>