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

[Mike Hearn]

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

That's true, I guess I was thinking that these buttons have to be
treated specially by the browser (to prevent scripts clicking them)
and stuff. But it's not such a big deal.

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

I'm confused. That's my point - <input type="storage"> was proposed to
ask that, and I suspect most people wouldn't understand the question.
If you just reuse the OS common file dialogs, it's not an issue (I
never saw an app tell me how big the file would be before I saved it,
I'm not convinced web apps would need to either if there was an
explicit save action involved).

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

I was thinking that the event handler would just provide a Storage
object, so the problem of origins isn't present.

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

Ahh, I didn't find the thread to contain much consensus at all :) I
will have to re-read it, as I don't remember what the arguments for
making stored data harder to find were.

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

Could you hint me where in the discussion they were spelled out? I saw
Linus' proposal, and Adrian Sutton raised the backup/file management
issue as well. But I didn't see much followup discussion of that. What
use case isn't possible under an explicit user-triggered model in
which a regular file/save mechanism is used (button or existing menu
option doesn't matter)?

I see that in low disk space conditions, you might lose things like
settings, but the existing OS behavior is even worse - if you run out
of disk space most desktop programs will panic and start corrupting
data. 99% of desktop software just isn't tested under failing write
conditions anymore. This is another reason why any system that
requires imposing quota seems likely to fail - most apps won't be
tested against that condition and will just crash or corrupt data when
they run out of quota even if the system actually has enough space to
succeed. Removing the oldest, least accessed files automatically seems
preferable to that, at least the data loss is controlled and affects
what you are NOT using, rather than what you are.

Of course no data loss at all is the most preferable, but that's what
servers are for :)

> Maybe you should reply to some of the original points (preferably in the
> original thread)?

I wasn't subscribed at that time, so I can't :-( Roll on Google Wave ....