<div class="gmail_quote">On Wed, Sep 15, 2010 at 12:47 AM, Eric Uhrhane <span dir="ltr"><<a href="mailto:ericu@google.com">ericu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, Sep 14, 2010 at 4:30 PM, Jim Williams <<a href="mailto:jgwilliams@mindspring.com">jgwilliams@mindspring.com</a>> wrote:<br>
> I see localStorage and sessionStorage as a chance to fix things that weren't<br>
> so good with cookies. So I'd be interested to know what factors actively<br>
> promote the failure to come up with a common browser-independent interface<br>
> for localStorage. Do browser builders actually have something to gain by<br>
> resisting interoperability here?<br>
<br>
</div>I think you're coming at it from a quite different point of view than<br>
browser builders usually have. When we implement e.g. our<br>
localStorage database, having it use the same file format as Opera is<br>
the furthest thing from our mind. Even if we wanted to share data<br>
with them, how would we make sure that we didn't both write the file<br>
at the same time? How would we know when to update our in-memory<br>
state from disk? What if you had multiple Firefox profiles that each<br>
used a different set of cookies--which profile should sync with Opera?<br>
<br>
These are huge problems and lots of work, and for very little payoff.<br></blockquote><div><br></div><div>Agreed. The number of people who use only one computer but multiple browsers pales in comparison to those who use multiple computers. Thus one user being able to use two browsers that share information would benefit very few users (at the expense of a lot of work). There are much bigger fish to fry.</div>
<div><br></div><div>J</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5">
> I'd also be interested to see some actual data on how often people switch<br>
> browsers. Much of my own browser-switching experiences have to do, not with<br>
> web development, but with online courseware that was designed to run on a<br>
> particular browser - and then I follow links on whatever browser I'm on at<br>
> the moment, so that the same sites often turn up on both browsers. I also<br>
> know nontechnical people who just like downloading and playing with stuff,<br>
> including browsers.<br>
><br>
> Also, yes, one could use the file system API in place of cookies or other<br>
> local storage, but that tends to interrupt the user's flow of thought, so<br>
> I'd prefer to avoid such heavy-handedness without having a good reason.<br>
><br>
> Tab Atkins Jr. wrote:<br>
><br>
> On Tue, Sep 14, 2010 at 4:52 AM, Jim Williams <<a href="mailto:jgwilliams@mindspring.com">jgwilliams@mindspring.com</a>><br>
> wrote:<br>
><br>
><br>
> I tried out local storage, used it to save the contents of a<br>
> content-editable passage. It worked great in Firefox, Chrome, Safari, and<br>
> MSIE. Only one problem: Every time I switched browsers, I had to start<br>
> over with the original unedited passage. So I have two requests.<br>
><br>
> 1. I would like the browser vendors to all use the same implementation of<br>
> localStorage, as this will greatly facilitate browser-independent viewing<br>
> experiences. As it stands, I have no idea how to maintain continuity if a<br>
> user viewing my page in one browser switches to another browser. None.<br>
><br>
><br>
> Like cookies, all browser data will be dependent on the browser.<br>
> There's very little chance of this ever changing.<br>
><br>
> Users rarely switch browsers, in any case. We web developers are a<br>
> rare exception.<br>
><br>
><br>
><br>
> 2. Kindly extend the specification so that other applications can make<br>
> constructive use of localStorage. Specifically, (a) establish a convention<br>
> for associating keys with particular files (e.g., by prepending the file's<br>
> path name to the key), and (b) allowing other applications to treat the file<br>
> and its associated local storage as a single entity. Doing this would allow<br>
> a user to e-mail the current state of a file to a friend, so that both will<br>
> have the same view of the file. This ability to share "current" views of a<br>
> file is useful for maintaining HTML's role as a communications vehicle.<br>
><br>
><br>
> The FileSystem API is designed for this use-case, so you can build a<br>
> file in javascript and ask the user to save it to their harddrive.<br>
><br>
> ~TJ<br>
><br>
><br>
><br>
</div></div></blockquote></div><br>