On Mon, Mar 5, 2012 at 9:10 PM, Brian Smith <[email protected]> wrote: > Jonas Sicking wrote: >> On Mon, Mar 5, 2012 at 7:47 PM, Brian Smith <[email protected]> >> > If I were a web app developer, in the short term I would try >> > putting as much in AppCache as possible, for browsers that don't >> > prompt for AppCache. > >> Hmm.. I actually disagree with you here. >> >> I don't think that we should try to bend the AppCache into >> supporting that usecase. > > We don't disagree here. My point is that if/when we remove the prompts for > AppCache, we should expect that web developers will use AppCache in this way. > In particular, if you're a web developer, and if putting resources in > AppCache means that your resources will get evicted with a lower priority > than some other website's normal resources, then why wouldn't you (ab)use it? > Just because that's not what it's for?
Yes! I definitely agree with this. It's an especially bad problem because things will look great right now when only a few sites uses the AppCache and so authors will push for adding all sorts of features to AppCache. But a year from now when everyone does, we'll be back here with the same problem set and not having actually solved anything, but wasted effort adding features that make the web platform more complex. Maybe one solution would be to not AppCache a website unless we see that the user goes there a lot. So if you visit a site for the first time, or the first time in a few weeks, then we simply would ignore the manifest attribute. But if we see that a user has visited the site 5 times the past week, we could stick it in the AppCache. >> As for using IndexedDB, I think that's too much of a complex solution >> for pages. It means that you can't simply stick <img >> src="somepic.jpg"> in your markup. Instead you have to use the DOM >> and a pile of JS in order to dynamically create a image element >> which loads data from IndexedDB. It'd work, but it means >> dramatically changing how people write web pages, IMHO for the >> worse. > > It is hard to talk about this without some specific use cases. I think a lot > of use cases are already handled in a pretty good way using XHR for > preloading things into the cache, if you're willing to make a separate > (hopefully pipelined/multiplexed) HTTP request for each one. Getting that to > work efficiently is more of a networking connection management problem than a > disk cache or database problem, AFAICT. > > Perhaps we should look at how we'd reimplement Thunderbird as a modern HTML5 > application (ignoring the lack of support for non-HTTP/non-websocket > networking) and see how we'd efficiently cache resources with it. (We will > need to implement such an email client for B2G anyway.) I think the thunderbird scenario is a somewhat simpler one. The solution there is basically AppCache. The part that feels more complex is sites like facebook or cnn.com where the user will be visiting a large number of URLs with a large number of resources in it. / Jonas _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
