<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3395" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><FONT face=Verdana size=2><SPAN
class=095213611-27082009>Speaking up as an application developer ;-) here,
I think the "evict data at browser's choice" route is fatal for new inventions
in app development. I've been hoping that WebStorage and Offline together
with other new APIs could provide a platform that allows us to build
applications free from dependencies to specific platforms/OSs (a no-brainer
for the web) and also freeing us from the tyranny of the 50-year old "file"
concept (information doesn't necessarily want to be contained in files, and most
of the time users don't want to do the additional task of administering file
names and folder structures on a local disk).</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Verdana size=2><SPAN
class=095213611-27082009></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Verdana size=2><SPAN
class=095213611-27082009>These new apps might not have a server at all, maybe
using peer-to-peer technologies to exchange parts of its data with the
outside world.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Verdana size=2><SPAN
class=095213611-27082009></SPAN></FONT><FONT face=Verdana size=2><SPAN
class=095213611-27082009></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Verdana size=2><SPAN
class=095213611-27082009>If, like many say here, </SPAN></FONT><FONT
face=Verdana size=2><SPAN class=095213611-27082009>a user file is
</SPAN></FONT><FONT face=Verdana size=2><SPAN
class=095213611-27082009>considered more precious than data in localStorage, and
the latter may have an automatic eviction scheme, then these new apps cannot use
WebStorage. Instead I would look forward to new File APIs, allowing me to store
data in local files. And then we are back to having our users handling
and managing files and folders on their local disk...</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Verdana size=2><SPAN
class=095213611-27082009></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Verdana size=2><SPAN
class=095213611-27082009>To back up a bit, offline data can be used to improve
applications in different ways, and here's a quick list of scenarios I come
to think of:</SPAN></FONT></DIV>
<UL dir=ltr>
<LI>
<DIV align=left><FONT face=Verdana size=2><SPAN class=095213611-27082009>the
browser makes an automatic decision to cache certain server
data</SPAN></FONT></DIV></LI>
<LI>
<DIV align=left><FONT face=Verdana size=2><SPAN class=095213611-27082009>the
application decides to cache certain server data without asking the
user</SPAN></FONT></DIV></LI>
<LI>
<DIV align=left><FONT face=Verdana size=2><SPAN class=095213611-27082009>the
application caches certain server data in response to user command ("I need to
have all my mail for offline access while I'm on the
plane")</SPAN></FONT></DIV></LI>
<LI>
<DIV align=left><FONT face=Verdana size=2><SPAN class=095213611-27082009>the
application allows creation of new data and modification of existing cached
server data while offline</SPAN></FONT></DIV></LI>
<LI>
<DIV align=left><FONT face=Verdana size=2><SPAN class=095213611-27082009>
<DIV align=left><FONT face=Verdana size=2><SPAN class=095213611-27082009>the
application allows creation and modification of data without relying on that
there is a server or a copy of the data on that
server</SPAN></FONT></DIV></SPAN></FONT></DIV></LI></UL>
<DIV dir=ltr align=left><FONT face=Verdana size=2><SPAN
class=095213611-27082009>If localStorage data is not considered precious I can
only see the first two types of caching possible in professional applications.
Even the third point would not be acceptable if the user has specifically asked
to have a certain subset of his data available while travelling the Amazonas,
just to discover that it was evicted because the browser decided
to.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Verdana size=2><SPAN
class=095213611-27082009></SPAN></FONT><FONT face=Verdana size=2><SPAN
class=095213611-27082009></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Verdana size=2><SPAN
class=095213611-27082009>As someone said, I think it is important that the spec
clarifies which of these scenarios </SPAN></FONT><FONT face=Verdana size=2><SPAN
class=095213611-27082009>WebStorage is aiming to fulfill.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Verdana size=2><SPAN
class=095213611-27082009></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Verdana size=2><SPAN
class=095213611-27082009>Best regards</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Verdana size=2><SPAN
class=095213611-27082009>Mike Wilson</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Verdana color=#0000ff
size=2></FONT> </DIV><FONT face=Verdana color=#0000ff></FONT>Drew
Wilson wrote:<SPAN class=095213611-27082009></SPAN><BR>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">This
is one of those times when I *really* wish that the application developer
community was more active on this list. I absolutely understand Linus' point
of view, but I also feel like we are really hamstringing applications when we
make choices like this and I wish that those developers were more vocally
represented in these types of discussions.
<DIV><BR></DIV>
<DIV>Going down this path would basically kill the ability to have offline web
applications, because there would be no guarantees that the data would persist
until the user comes back online. But since that point's already been made
several times, I guess it's not a compelling argument.<BR>
<DIV>
<DIV>
<DIV><BR></DIV>
<DIV>-atw</DIV>
<DIV><BR>
<DIV class=gmail_quote>On Wed, Aug 26, 2009 at 8:23 PM, Linus Upson <SPAN
dir=ltr><<A href="mailto:linus@google.com">linus@google.com</A>></SPAN>
wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">I
simply want clicking on links to be safe. In a previous thread I wrote "safe
and stateless" but I'm coming to the opinion that stateless is
a corollary of safe. Clicking on links shouldn't, either by
filling my disk or hitting my global quota, someday lead to a dialog which
reads, "Please choose what to delete so that web sites will continue to
work." The candidate delete list will be thousands long and hidden in that
haystack will be a few precious needles.
<DIV><BR></DIV>
<DIV>I also want to avoid any [Yes] [No] dialogs. Can I do something scary
[Yes] [No]? Can I do something innocuous [Yes] [No]? Users shouldn't be
forced to make those kinds of safety judgements. I'm guilty of instigating
at least one of those dialogs. As shamed politicians do I'll retreat to the
passive voice: Mistakes were made.</DIV>
<DIV><BR></DIV>
<DIV>I'm not opposed to web apps manipulating files on the user's computer,
but the user should be in explicit control. I'd support <input
type="open"> and <input type="save"> that worked similarly to
<input type="file">. User agents are already registering for file
types so that double clicking a file with a certain extension can be
automatically sent to an URL, perhaps residing in an AppCache.</DIV>
<DIV><BR></DIV>
<DIV>In addition, I'd like to see the pop-up dialogs for the location API
removed. I find the "Can I know where you are?" dialogs on the iPhone very
annoying. Mistakes were made. Perhaps we can find a way to make <input
type="location"> work well instead.</DIV>
<DIV><BR></DIV><FONT color=#888888>
<DIV>Linus</DIV></FONT>
<DIV>
<DIV></DIV>
<DIV class=h5>
<DIV><BR></DIV>
<DIV><BR></DIV>
<DIV>
<DIV class=gmail_quote>On Wed, Aug 26, 2009 at 5:14 PM, Brady Eidson <SPAN
dir=ltr><<A href="mailto:beidson@apple.com"
target=_blank>beidson@apple.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">I
started writing a detailed rebuttal to Linus's reply, but by the time I
was finished, many others had already delivered more targetted
replies.<BR><BR>So I'll cut the rebuttal format and make a few specific
points.<BR><BR> - Many apps act as a "shoebox" for managing specific
types of data, and users are used to using these apps to manage that data
directly. See iTunes, Windows Media Player, iPhoto, and desktop mail
clients as examples. This trend is growing, not waning.
Browsers are already a "shoebox" for history, bookmarks, and other
types of data.<BR>Claiming that this data is "hidden" from users who are
used to handling obscure file management scenarios and therefore we
shouldn't fully respect it is trying to fit in with the past, not trying
to make the future better.<BR><BR> - No one is suggesting that UAs
not have whatever freedom they want in deciding *what* or *how much* to
store. We're only suggesting that once the UA has committed to
storing it, it *not* be allowed to arbitrarily purge it.<BR><BR> -
One use of LocalStorage is as a cache for data that is transient and
non-critical in nature, or that will live on a server. But another,
just-as-valid use of LocalStorage is for persistent, predictable storage
in the client UA that will never rely on anything in the
cloud.<BR><BR> - And on that note, if developers don't have faith
that data in LocalStorage is actually persistent and safe, they won't use
it.<BR>I've given talks on this point 4 times in the last year, and I am
stating this as a fact, based on real-world feedback from actual,
real-world web developers: If LocalStorage is defined in the
standard to be a purgable cache, developers will continue to use what
they're already comfortable with, which is Flash's
LocalStorage.<BR><BR>When a developer is willing to instantiate a plug-in
just to reliably store simple nuggets of data - like user preferences and
settings - because they don't trust the browser, then I think we've failed
in moving the web forward.<BR><BR>I truly hope we can sway the
"LocalStorage is a cache crowd." But if we can't, then I would have
to suggest something crazy - that we add a third Storage
object.<BR><BR>(Note that Jens - from Google - has already loosely
suggested this)<BR><BR>So we'd have something like:<BR>-SessionStorage -
That fills the "per browsing context" role and whose optionally transient
nature is already well spec'ed<BR>-CachedStorage - That fills Google's
interpretation of the "LocalStorage" role in that it's global, and "will
probably be around on the disk in the future, maybe"<BR>-FileStorage -
That fills Apple's interpretation of the "LocalStorage" role in that it's
global, and is as sacred as a file on the disk (or a song in your media
library, or a photo in your photo library, or a bookmark,
or...)<BR><BR>The names are just suggestions at this point.<BR><FONT
color=#888888><BR>~Brady<BR><BR><BR></FONT></BLOCKQUOTE></DIV><BR></DIV></DIV></DIV></BLOCKQUOTE></DIV><BR></DIV></DIV></DIV></DIV></BLOCKQUOTE></BODY></HTML>