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? > 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.) - Brian _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
