I'm one of the lurking web application developers. This discussion has
gone mostly how I was hoping, but since 'offline apps' has come up
again, I might bootstrap that a bit. Below are some use cases, but I'll
summarize my perspective briefly.
1. To run Doom requiring 500M of localStorage sounds like an
'application'--both users and developers currently have the expectation
that users have to approve something like that before being installed to
their computers to consume possibly valuable resources. A preliminary
prompt to the user sounds reasonable and expected here.
2. Once, I've approved of an application to store data locally, that
data could very easily be incredibly precious to both user and
developer. Neither would want that data to be swept away by a
garbage-collecting browser without user/developer action.
3. If the developer is presented with an unprompted option to store data
permanently or just have it 'cached'--I'm not sure why the developer
(both the nefarious and the good) would ever opt for the only-cached
version.
4. We'd like either (OffTopic)
a. localStorage to work for file://
AND/OR
b. there to be some way for someone with file access to change the
manifest file cache in offline applications (while preserving
SOME USE CASES
--------------
Where I work (http://ccnmtl.columbia.edu), we have two main use cases
for offline applications, which would be great if they were accomodated
in the spec and even more importantly, browsers :-)
1. Static deployment as an 'offline app'
http://ccnmtl.columbia.edu/portfolio/medicine_and_health/masivukeni.html
Requirements/Constraints:
* We were most familiar with programming and deploying web
applications, so we preferred to use html/js (and python for backend to
content development)
* The application was to be run on a laptop which could not (and
should not) connect to the Internet while being used.
* Data (including user accounts) is then maintained using localStorage.
* Rare updates (for critical bugs, e.g.) would not require online
access again.
Experience/Lessons:
* We deployed this with Firefox's legacy globalStorage (before ffox3.5
came out) and static html files accessed at file://
* As written, it no longer works in ffox 3.5 or even with updates to
ffox 3.0, because whereas file://localhost/ once worked (and thus
globalStorage['localhost']), but seems to have been removed.
Thankfully, as deployed, it's not connected to the Internet to receive
updates :-)
* If we implemented it again (which we will!) for HTML5, we would have
the laptop download the files as an offline app with a manifest. Then
localStorage would (hopefully) still work, and work upon visiting the
domain--even offline. However, this might cause problems in updating
the cached files without bringing the computer back online.
2. Deprecating experience for unprivileged users.
* We have some services which allow annotation of primary sources
(video/audio/images).
* Some of these sites have public content, but we do not have the
resources or interest in storing annotation/analysis from other users.
Nonetheless, we've considered offline storage as a way to allow
non-privileged users to analyze the content and store their data
locally--to be saved for their own benefit and possibly later to be
uploaded or shared elsewhere.
In concluding, many thanks to all those that are working on HTML5 (esp.
the browser vendors). It's an exciting time to be a web developer.
cheers,
Schuyler
> Message: 1
> Date: Wed, 26 Aug 2009 20:54:12 -0700
> From: Drew Wilson <atwil...@google.com>
> To: Linus Upson <li...@google.com>
> Cc: Brady Eidson <beid...@apple.com>, WHATWG List <wha...@whatwg.org>,
> Jeremy Orlow <jor...@chromium.org>, Jens Alfke <s...@google.com>,
> Aaron Boodman <a...@google.com>
> Subject: Re: [whatwg] Web Storage: apparent contradiction in spec
> Message-ID:
> <f965ae410908262054y7d405cbdq2f7b115c7b694...@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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 <li...@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 <beid...@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
>>>
>>>
>>>
