> What about the benefit that the web brings to updating the user's install
What about the detriment the web brings to having apps that work offline reliably and ensure control over their own data?
> Notify the users to keep their equipment on the network from time X to Y
Not your problem. Have your packaged app in the place its expected to be updated from (a HTTPS server for something like Sparkle framework, and/or the respective App stores).
The client will periodically check for updates and download the new version.
If your back-end functionality somehow changes in a way that breaks the old version (or something changes such that the old version cannot be allowed to operate, such as a law changing) - you simply use a versioned API in your backend, and respond to requests to the old version of the API, with an error message telling user an update is required.
> Your app is not the product. Your app is tool to get the product: information
That makes a huge assumption about the purpose of the app. If the app in question is a game, or an image editor, or a word processor or any number of other types of app - the app very much is the product.
> If it lacks UX for native, don't target native. Target app-y
And say goodbye to customers. People like the experience of a real native app.
When did having my own data stored in regular files become "strange"?
If the data is tied to a browser, how do I back it up/save a copy of it? How do I persist it when the browsers local settings/cache are cleared (either by clearing or eg. when the OS is installed)?
When did having my own data stored in regular files become "strange"?
I meant your wording was strange. I had to reread it several times to understand what you meant, and I think the parent poster also didn't understand what you meant.
If the data is tied to a browser, how do I back it up/save a copy of it?
In Firefox, back up your profile.
How do I persist it when the browsers local settings/cache are cleared (either by clearing or eg. when the OS is installed)?
If you clear it intentionally then why should it persist?
that's hardly the same as having a file i can copy and use anywhere.
> If you clear it intentionally then why should it persist?
In Safari at least, "local storage" is cleared when clearing other data like cookies etc. I would imagine that's not unique to Safari.
You also failed to cover the concept of "the OS is re-installed" or "a new device is purchased".
"Backup your firefox profile" is an unbelievably short-sighted suggestion - am I supposed to keep transporting a Firefox profile around forever? What if I want to use a different browser? What if I want to use my data on a device that doesn't expose the raw filesystem to the user, and thus I can't copy my profile to the correct location (assuming it was even binary compatible)?
I can't believe I have to explain the benefits of a regular file with data in it, to a directory containing a mix of browsing history, cookies, crash dumps, plugin information, and somewhere, an SQLite database containing my data.
>"Backup your firefox profile" is an unbelievably short-sighted suggestion - am I supposed to keep transporting a Firefox profile around forever?
Yes?
It's like asking whether you should keep your homedir or Windows Roaming User folder around forever. If you want your data and/or settings, you do. And both of those fit the description in your last line pretty well.
You're offended at the suggestion but it's the same way it works in native apps in reality.
> It's like asking whether you should keep your homedir or Windows Roaming User folder around forever.
No it isn't. A Firefox profile is a folder full of a mishmash of data, the vast majority of which is inherently not data I want to keep.
I deliberately don't keep my entire home folder when I re-install/upgrade OS X. I get much better results taking a short time to re-set a few preferences than deal with the effects of a carried-over ~/Library folder.
That's exactly what the Firefox profile folder is like - it's not just user data from local storage, it's fucking cookies and crash dumps and shit. Why would I ever want to keep that stuff forever?
> it's the same way it works in native apps in reality
It just really isn't, and it's not surprising that you chose to ignore all the other issues I raised with this suggested "solution".
What about the detriment the web brings to having apps that work offline reliably and ensure control over their own data?
> Notify the users to keep their equipment on the network from time X to Y
Not your problem. Have your packaged app in the place its expected to be updated from (a HTTPS server for something like Sparkle framework, and/or the respective App stores).
The client will periodically check for updates and download the new version.
If your back-end functionality somehow changes in a way that breaks the old version (or something changes such that the old version cannot be allowed to operate, such as a law changing) - you simply use a versioned API in your backend, and respond to requests to the old version of the API, with an error message telling user an update is required.
> Your app is not the product. Your app is tool to get the product: information
That makes a huge assumption about the purpose of the app. If the app in question is a game, or an image editor, or a word processor or any number of other types of app - the app very much is the product.
> If it lacks UX for native, don't target native. Target app-y
And say goodbye to customers. People like the experience of a real native app.