Jonas Sicking wrote:
> On Mon, Mar 5, 2012 at 7:47 PM, Brian Smith <
bsmith@mozi...>
> > 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
dev-tech-network@list...
https://lists.mozilla.org/listinfo/dev-tech-network
opensubscriber is not affiliated with the authors of this message nor responsible for its content.