LocalStorage: Difference between revisions

2,934 bytes added ,  25 November 2006
m
Reverted edit of Wpiocs, changed back to last version by Udayan
(add notes about functional coverage)
m (Reverted edit of Wpiocs, changed back to last version by Udayan)
 
(5 intermediate revisions by 3 users not shown)
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>
:::[[User:udayan|udayan]]One more set of problems arises with deployment of applications in geogaphically remote areas. These areas have connectivity on a very limited basis ( not 24 X 7 ), connectivity is of poor quality ( speed and reliability ) and connectivity is expensive. Also the remoteness means applications deployed in such areas need to be remotely managable, as physical access is not always feasible. This creates a need for the applications to be : (a) Remote depoyable and managable and (b) Applications must work in offline mode ( forms data based data entry, locally cached, submitted on detection of connectivity, upgrades to application and things like form templates to be cownloaded on detection of connectivity ).
:::For this we need the ability in the browser to be able to explicitly tag content  as "offline capable", where "offline capable" would imply a set of things and not just being able to "pin" content in a cache.


===Storage===
===Storage===
Confirmed users
503

edits