[whatwg] Resolving the persistent vs cache dilemma with file|save

On Wed, Sep 23, 2009 at 2:53 PM, Mike Hearn <mike at plan99.net> wrote:

> The closest suggestion I saw was Linus' <input type="storage"> which
> isn't quite the same:
>
> 1) Triggered from web page rather than browser chrome with associated
> security issues
>

What security issues?  There aren't any issues with the file selector box,
right?  How is this different?


> 2) Explicit quota request (i think MB/GB isn't a meaningful unit of
> measure for most people)
>

You'd get this with the input button as well.


> 3) Doesn't solve the fact that file|save doesn't work for web apps
>

This is a somewhat compelling argument.  We'd have to completely change how
LocalStorage works for file:/// urls though, right?


> 4) No selection of paths or files was mentioned, so, how will users
> know what to back up/put on USB keys etc?
>

The discussion in the thread generally found this to be a good
thing...though there was't 100% consensus.


> 5) Freeing up space is done in the same way it is today - by deleting
> files using a file manager
>

As we discussed, it's not clear this is a good thing.  :-)


> So I think this proposal will work better, at least a little bit. It
> avoids introducing new UI elements at least.
>

I'm not sure if that's a good thing or not.  It also still has most if not
all of the downsides to the input box.


> > I'm not saying there's no merit to this, but since the thread was not
> that
> > long ago, I don't think the burden should be on everyone on this list to
> > re-explain their points.
>
> Perhaps I should have been clearer. I read the whole "apparent
> contradiction in spec" thread. If there was similar discussion in
> other threads .... well, it's impossible to read the whole whatwg
> archives even for a couple of months. That's a lot of mail! I hope I
> read the parts relevant for this discussion.
>

That is the thread I was talking about.  You said "didn't read the whole
thing which is why I assumed you hadn't read that whole thread.

Anyway, to prove I did actually read it, I believe Jens Alfke said
>
> > Replace "user agent" -> "operating system" and "local state" -> "user
> > files", and you have an argument that, when the hard disk in my
> > MacBook gets too full, the OS should be free to start randomly
> > deleting my local files to make room. This would be a really bad idea.
>
> Isn't that exactly the idea behind Chrome OS? If files are backed up
> to the cloud then the entire local storage can be seen as one big
> cache and the OS would indeed start deleting local files when storage
> got full, redownloading them as required.
>

I think this is one of the reasons Linus was arguing so strongly for us not
to add any API that is more than just a cache.  :-)


> Arguably that just moves the "storage full" problem to the server, but
> then again, nothing except the potential for accidents stops a company
> offering "infinite" quota and charging only for what is used, in which
> case, you might never run out of space.
>
> This "cloud vs desktop" platform thing seems to be a key area of
> disagreement. I'm firmly in the cloud camp - writing HTML5 apps
> independent of a server seems isn't something I understand.
> JavaScript+HTML aren't going to beat .NET/Mono/Java at their own game,
> so why even try? The thing that makes web apps interesting is the very
> fact that they _are_ deeply integrated with the internet, are simple,
> they don't require explicit management etc.
>
> If HTML5 ends up changing these attributes just to be yet another API
> over the same old paradigm of downloadable, installable apps that
> generate DOC files or whatever, it won't have achieved very much.
>

Sure.  And there are some in your camp, but for the most part people
disagree.  And gave some good reasons why they disagree.  For example, Jens'
TiddlyWiki example.  Another is composing an email while offline.

Maybe you should reply to some of the original points (preferably in the
original thread)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090923/98256aa8/attachment-0001.htm>

Received on Wednesday, 23 September 2009 15:15:45 UTC