6
edits
LocalStorage: Difference between revisions
notes about roc's comments
(add notes about functional coverage) |
(notes about roc's comments) |
||
| Line 85: | Line 85: | ||
:Instead of providing a manifest, a more Web-friendly approach might be to crawl the page. Basically, when you select a page for offline viewing (which could be as simple as just bookmarking it), we pin it and also download and pin any of the resources we would if we were doing Save As --- images, stylesheets, scripts, IFRAMEs. In addition we could provide a new 'rel' value for <a> links that says "crawl this link for offline viewing". This would be really easy for Web developers to use and maintain and not too difficult to implement, I suspect. Application crawling and download could be done in the background. | :Instead of providing a manifest, a more Web-friendly approach might be to crawl the page. Basically, when you select a page for offline viewing (which could be as simple as just bookmarking it), we pin it and also download and pin any of the resources we would if we were doing Save As --- images, stylesheets, scripts, IFRAMEs. In addition we could provide a new 'rel' value for <a> links that says "crawl this link for offline viewing". This would be really easy for Web developers to use and maintain and not too difficult to implement, I suspect. Application crawling and download could be done in the background. | ||
::[[User:Blizzard|Blizzard]] Pinning pages in the cache sounds like a great idea as a way to implement this, but I don't think using a heuristic that eventually asks the user to add storage is probably the right way to go. Users don't often know how big their cache is nor how much space they have left on their hard drive. I did have a hook for the actual application to throw the space dialog, but that's a little different than the browser throwing that dialog. That requires the app knowing how much space is allocated to it and how much space it is using. The nice thing about that is the app can avoid ever throwing that dialog by expiring data instead of requiring the user to just add more data. | |||
::I also think that it's important that we keep the maifest separate from the pages themselves for a few reasons: | |||
::<ol><li>It's hard to know where an offline application "starts." That is, if you're on page X does that app start on page X or on another page entirely? The manifest is the logical starting point for the "bookmark" and can also contain "start" information. i.e. which cached page should be loaded when you are offline and the bookmark is loaded? <li>When do you expire data? If you update your offline app how do you tell when certain pages are unused? If there's no single location for all of the pages to be found upgrades can get a lot more challenging and there's a good chance that we'll end up with some unpredictable heuristic. <li>Raw crawling misses a lot of data. Urls and locations that are accessed via javascript and building form data on the fly can create locations that won't show up in a crawl. <li>It would be a lot of work to maintain all of the possible links in all of your pages. I think it would be a lot easier just to have a simple text-based file that contains a list of resources for all of the pages. And a simple <link> page that links to that manifest. Everything is explicit and well-understood in that case.</ol> | |||
===Storage=== | ===Storage=== | ||