[whatwg] Web Storage: apparent contradiction in spec

[Mike Wilson]

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).
 
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.
 
If, like many say here, a user file is 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...
 
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:

*	

	the browser makes an automatic decision to cache certain server data
*	

	the application decides to cache certain server data without asking
the user
*	

	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")
*	

	the application allows creation of new data and modification of
existing cached server data while offline
*	

	
	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

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.
 
As someone said, I think it is important that the spec clarifies which of
these scenarios WebStorage is aiming to fulfill.
 
Best regards
Mike Wilson
 
Drew Wilson wrote:


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. 

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.


-atw

On Wed, Aug 26, 2009 at 8:23 PM, Linus Upson <linus at google.com> wrote:


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. 

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.

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.

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.


Linus


On Wed, Aug 26, 2009 at 5:14 PM, Brady Eidson <beidson at apple.com> wrote:


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.

So I'll cut the rebuttal format and make a few specific points.

 - 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.
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.

 - 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.

 - 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.

 - And on that note, if developers don't have faith that data in
LocalStorage is actually persistent and safe, they won't use it.
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.

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.

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.

(Note that Jens - from Google - has already loosely suggested this)

So we'd have something like:
-SessionStorage - That fills the "per browsing context" role and whose
optionally transient nature is already well spec'ed
-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"
-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...)

The names are just suggestions at this point.

~Brady






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090827/2060daaa/attachment-0002.htm>