Re: Collecting real world use cases (Was: Fixing appcache: a proposal to get us started)
On 02.05.13 06:58, Charles McCathie Nevile cha...@yandex-team.ru wrote: On Thu, 18 Apr 2013 19:19:17 +0300, Paul Bakaus pbak...@zynga.com wrote: Hi Jonas, Thanks for this I feel this is heading somewhere, finally! I still need to work on submitting my full feedback, but I'd like to mention this: Why did nobody so far in this thread include real world use cases? For a highly complex topic like this in particular, I would think that collecting a large number of user use cases, not only requirements, and furthermore finding the lowest common denominator based on them, would prove very helpful, even if it's just about validation and making people understand your lengthy proposal. I.e. a news reader that needs to sync content, but has an offline UI. Do you have a list collected somewhere? I started to collect them: http://www.w3.org/wiki/Webapps/AppCacheUseCases Excellent, thanks! So far I added the stuff from this thread in very rough form. I think it is helpful in the Wiki to name people who are actually trying to implement this stuff (the more the merrier, obviously) so we know who are the minimum set of people to talk to about reviewing solutions etc. I will add Zynga to the list. cheers Chaals Thanks! Paul On 26.03.13 16:02, Jonas Sicking jo...@sicking.cc wrote: Hi WebApps! Apologies in advance for a long email. This is a complex subject and I wanted to present a coherent proposal. Please don't be shy about starting separate threads when providing feedback. There has been a lot of debating about fixing appcache. Last year mozilla got a few people together mostly with the goal of understanding what the actual problems were. The notes from that meeting are available at [1]. Those discussions, and a few followup ones, has made it clear that there were a few big ticket items that we needed to fix: * The fact that master entries are automatically added to the cache works very poorly for a lot of developers. * Once a website is cached the user will only see the new version on second load, even if the user is online. This is good for performance but is a behavior many websites aren't willing to live with. * You have to tweak a comment of the manifest in order to trigger an update-check of the cached resources. * We need an escape hatch for people running into missing features in the appcache. I.e. a way for websites to use script to complement the set of behaviors supported by the appcache spec. * The fact that FALLBACK combined the hit network first, fall back to a cached resource and allow a cached resource to handle requests to a whole URL space behaviors is problematic since many times you want one and not the other. * People want to use appcache not just to make offline apps possible, but also make online apps fast. * There isn't enough ability to control the appcache through javascript. There are certainly other things that people have mentioned, but the above have been a reoccurring theme. Feel free to comment here if you have other issues with the current appcache, but it might be worth doing that as separate threads. I believe that some of these problems stem from a relatively small set of design problems: The appcache appears to be aimed at too simple applications. It works fine if the website you want to cache consists of a small set of static resources and otherwise only use features like IndexedDB or localStorage to manage dynamic data. But once an application uses server-side processing to dynamically generate resources based on query parameters or other parts of the URL, then it requires that you change the way that your application works. Another design aspect that appears to be causing problem is that appcache is optimized too heavily for minimizing the amount of typing that the author had to do. It attempts to help the author too much, for example by automatically adding master entries that link to an appcache but aren't enumerated in it. Or automatically adding the handler URLs from the FALLBACK section to the set of URLs to be automatically downloaded. The result is that the appcache contains too much magic. In theory an author can just type very little and the appcache will automatically do the right thing. However this magic is making it too hard for authors to understand what's going on. The result is that people don't use the appcache even if they might have needed to type very little to get it working. Implementations certainly hasn't helped here either, by not exposing the behind-the-scenes logic through debugging and developer tools. The fact that the appcache is aimed at simple applications is generally a good thing given that it's the first version. However the desire to make applications available offline, as well as make them faster when the user is online, has been so great that people have wanted to use the appcache to solve a larger set of types of applications. So to some
Re: Collecting real world use cases (Was: Fixing appcache: a proposal to get us started)
On Thu, 18 Apr 2013 19:19:17 +0300, Paul Bakaus pbak...@zynga.com wrote: Hi Jonas, Thanks for this I feel this is heading somewhere, finally! I still need to work on submitting my full feedback, but I'd like to mention this: Why did nobody so far in this thread include real world use cases? For a highly complex topic like this in particular, I would think that collecting a large number of user use cases, not only requirements, and furthermore finding the lowest common denominator based on them, would prove very helpful, even if it's just about validation and making people understand your lengthy proposal. I.e. a news reader that needs to sync content, but has an offline UI. Do you have a list collected somewhere? I started to collect them: http://www.w3.org/wiki/Webapps/AppCacheUseCases So far I added the stuff from this thread in very rough form. I think it is helpful in the Wiki to name people who are actually trying to implement this stuff (the more the merrier, obviously) so we know who are the minimum set of people to talk to about reviewing solutions etc. cheers Chaals Thanks! Paul On 26.03.13 16:02, Jonas Sicking jo...@sicking.cc wrote: Hi WebApps! Apologies in advance for a long email. This is a complex subject and I wanted to present a coherent proposal. Please don't be shy about starting separate threads when providing feedback. There has been a lot of debating about fixing appcache. Last year mozilla got a few people together mostly with the goal of understanding what the actual problems were. The notes from that meeting are available at [1]. Those discussions, and a few followup ones, has made it clear that there were a few big ticket items that we needed to fix: * The fact that master entries are automatically added to the cache works very poorly for a lot of developers. * Once a website is cached the user will only see the new version on second load, even if the user is online. This is good for performance but is a behavior many websites aren't willing to live with. * You have to tweak a comment of the manifest in order to trigger an update-check of the cached resources. * We need an escape hatch for people running into missing features in the appcache. I.e. a way for websites to use script to complement the set of behaviors supported by the appcache spec. * The fact that FALLBACK combined the hit network first, fall back to a cached resource and allow a cached resource to handle requests to a whole URL space behaviors is problematic since many times you want one and not the other. * People want to use appcache not just to make offline apps possible, but also make online apps fast. * There isn't enough ability to control the appcache through javascript. There are certainly other things that people have mentioned, but the above have been a reoccurring theme. Feel free to comment here if you have other issues with the current appcache, but it might be worth doing that as separate threads. I believe that some of these problems stem from a relatively small set of design problems: The appcache appears to be aimed at too simple applications. It works fine if the website you want to cache consists of a small set of static resources and otherwise only use features like IndexedDB or localStorage to manage dynamic data. But once an application uses server-side processing to dynamically generate resources based on query parameters or other parts of the URL, then it requires that you change the way that your application works. Another design aspect that appears to be causing problem is that appcache is optimized too heavily for minimizing the amount of typing that the author had to do. It attempts to help the author too much, for example by automatically adding master entries that link to an appcache but aren't enumerated in it. Or automatically adding the handler URLs from the FALLBACK section to the set of URLs to be automatically downloaded. The result is that the appcache contains too much magic. In theory an author can just type very little and the appcache will automatically do the right thing. However this magic is making it too hard for authors to understand what's going on. The result is that people don't use the appcache even if they might have needed to type very little to get it working. Implementations certainly hasn't helped here either, by not exposing the behind-the-scenes logic through debugging and developer tools. The fact that the appcache is aimed at simple applications is generally a good thing given that it's the first version. However the desire to make applications available offline, as well as make them faster when the user is online, has been so great that people have wanted to use the appcache to solve a larger set of types of applications. So to some extent the appcache has been a victim of its own success. The other week a few of us at mozilla got together to discuss how to fix appcache. I.e. how to come up with a solution for the above
Re: Collecting real world use cases (Was: Fixing appcache: a proposal to get us started)
I think there are some good use cases for not-quite-offline as well. Sort of a combination of your twitter and wikipedia use cases: Community-content site: Logged-out users have content cached aggressively offline - meaning every page visited should be cached until told otherwise. Intermediate caches / proxies should be able to cache the latest version of a URL. As soon as a user logs in, the same urls they just used should now have editing controls. (note that actual page contents *may* not have not changed, just the UI) Pages now need to be fresh meaning that users should never edit stale content. In an ideal world, once a logged in user has edited a page, that page is pushed to users or proxies who have previously cached that page and will likely visit it again soon. I know this example in particular seems like it could be accomplished with a series of If-Modified-Since / 304's, but connection latency is the killer here, especially for mobile - the fact that you have a white screen while you wait to see if the page has changed. The idea that you could visit a cached page, (i.e. avoid hitting the network) and then a few seconds later be told there is a newer version of this page available after the fact, (or even just silently update the page so the next visit delivers a fresh but network-free page) would be pretty huge. Especially if you could then proactively fetch a select set of pages - i.e. imagine an in-browser process that says for each link on this page, if I have a stale copy of the url, go fetch it in the background so it is ready in the cache (On this note it would probably be worth reaching out to the wiki foundation to learn about the hassle they've gone through over the years trying to distribute the load of wikipedia traffic given the constraints of HTTP caching, broken proxies, CDNs, ISPs, etc) Alec On Tue, Apr 30, 2013 at 9:06 PM, Jonas Sicking jo...@sicking.cc wrote: On Apr 18, 2013 6:19 PM, Paul Bakaus pbak...@zynga.com wrote: Hi Jonas, Thanks for this I feel this is heading somewhere, finally! I still need to work on submitting my full feedback, but I'd like to mention this: Why did nobody so far in this thread include real world use cases? For a highly complex topic like this in particular, I would think that collecting a large number of user use cases, not only requirements, and furthermore finding the lowest common denominator based on them, would prove very helpful, even if it's just about validation and making people understand your lengthy proposal. I.e. a news reader that needs to sync content, but has an offline UI. Do you have a list collected somewhere? Sorry for not including the list in the initial email. It was long enough as it was so I decided to stop. Some of the use cases we discussed were: Small simple game The game consists of a set of static resources. A few HTML pages, like high score page, start page, in-game page, etc. A larger number of media resources. A few data resources which contain level metadata. Small amount of dynamic data being generated, such as progress on each level, high score, user info. In-game performance is critical, all resources must be guaranteed to be available locally once the game starts. Little need for network connectivity other than to update game resources whenever an update is available. Advanced game Same as simple game, but also downloads additional levels dynamically. Also wants to store game progress on servers so that it can be synced across devices. Wikipedia Top level page and its resources are made available offline. Application logic can enable additional pages to be made available offline. When such a page is made available offline both the page and any media resources that it uses needs to be cached. Doesn't need to be updated very aggressively, maybe only upon user request. Twitter A set of HTML templates that are used to create a UI for a database of tweets. The same data is visualized in several different ways, for example in the user's default tweet stream, in the page for an individual tweet, and in the conversation thread view. Downloading the actual tweet contents and metadata shouldn't need to happen multiple times in order to support the separate views. The URLs for watching individual tweets needs to be the same whether the user is using appcache or not so that linking to a tweet always works. It is very important that users are upgraded to the latest version of scripts and templates very quickly after they become available. The website likely will want to be able to check for updates on demand rather than relying on implementation logic. If the user is online but has appcached the website it should be able to use the cached version. This should be the case even if the user navigates to a tweet page for a tweet for which the user hasn't yet cached the tweet content or metadata. In this case only the tweet content and metadata
Re: Collecting real world use cases (Was: Fixing appcache: a proposal to get us started)
Hi Jonas, hi Alec, I think all of this is great stuff that helps a ton – thanks! Let's definitely put them onto a wiki somewhere. Charles: Where would be the right place to put that list? I'm imagining a big table with columns for the proposal and then each of the AppCache 2.0 proposals validated against it in the others. Thanks, Paul From: Alec Flett alecfl...@chromium.orgmailto:alecfl...@chromium.org Date: Wed, 1 May 2013 08:50:33 -0700 To: Jonas Sicking jo...@sicking.ccmailto:jo...@sicking.cc Cc: Paul Bakaus pbak...@zynga.commailto:pbak...@zynga.com, Webapps WG public-webapps@w3.orgmailto:public-webapps@w3.org Subject: Re: Collecting real world use cases (Was: Fixing appcache: a proposal to get us started) I think there are some good use cases for not-quite-offline as well. Sort of a combination of your twitter and wikipedia use cases: Community-content site: Logged-out users have content cached aggressively offline - meaning every page visited should be cached until told otherwise. Intermediate caches / proxies should be able to cache the latest version of a URL. As soon as a user logs in, the same urls they just used should now have editing controls. (note that actual page contents *may* not have not changed, just the UI) Pages now need to be fresh meaning that users should never edit stale content. In an ideal world, once a logged in user has edited a page, that page is pushed to users or proxies who have previously cached that page and will likely visit it again soon. I know this example in particular seems like it could be accomplished with a series of If-Modified-Since / 304's, but connection latency is the killer here, especially for mobile - the fact that you have a white screen while you wait to see if the page has changed. The idea that you could visit a cached page, (i.e. avoid hitting the network) and then a few seconds later be told there is a newer version of this page available after the fact, (or even just silently update the page so the next visit delivers a fresh but network-free page) would be pretty huge. Especially if you could then proactively fetch a select set of pages - i.e. imagine an in-browser process that says for each link on this page, if I have a stale copy of the url, go fetch it in the background so it is ready in the cache (On this note it would probably be worth reaching out to the wiki foundation to learn about the hassle they've gone through over the years trying to distribute the load of wikipedia traffic given the constraints of HTTP caching, broken proxies, CDNs, ISPs, etc) Alec On Tue, Apr 30, 2013 at 9:06 PM, Jonas Sicking jo...@sicking.ccmailto:jo...@sicking.cc wrote: On Apr 18, 2013 6:19 PM, Paul Bakaus pbak...@zynga.commailto:pbak...@zynga.com wrote: Hi Jonas, Thanks for this I feel this is heading somewhere, finally! I still need to work on submitting my full feedback, but I'd like to mention this: Why did nobody so far in this thread include real world use cases? For a highly complex topic like this in particular, I would think that collecting a large number of user use cases, not only requirements, and furthermore finding the lowest common denominator based on them, would prove very helpful, even if it's just about validation and making people understand your lengthy proposal. I.e. a news reader that needs to sync content, but has an offline UI. Do you have a list collected somewhere? Sorry for not including the list in the initial email. It was long enough as it was so I decided to stop. Some of the use cases we discussed were: Small simple game The game consists of a set of static resources. A few HTML pages, like high score page, start page, in-game page, etc. A larger number of media resources. A few data resources which contain level metadata. Small amount of dynamic data being generated, such as progress on each level, high score, user info. In-game performance is critical, all resources must be guaranteed to be available locally once the game starts. Little need for network connectivity other than to update game resources whenever an update is available. Advanced game Same as simple game, but also downloads additional levels dynamically. Also wants to store game progress on servers so that it can be synced across devices. Wikipedia Top level page and its resources are made available offline. Application logic can enable additional pages to be made available offline. When such a page is made available offline both the page and any media resources that it uses needs to be cached. Doesn't need to be updated very aggressively, maybe only upon user request. Twitter A set of HTML templates that are used to create a UI for a database of tweets. The same data is visualized in several different ways, for example in the user's default tweet stream, in the page for an individual tweet, and in the conversation thread view. Downloading the actual tweet contents and metadata shouldn't need to happen
Re: Collecting real world use cases (Was: Fixing appcache: a proposal to get us started)
On Apr 18, 2013 6:19 PM, Paul Bakaus pbak...@zynga.com wrote: Hi Jonas, Thanks for this I feel this is heading somewhere, finally! I still need to work on submitting my full feedback, but I'd like to mention this: Why did nobody so far in this thread include real world use cases? For a highly complex topic like this in particular, I would think that collecting a large number of user use cases, not only requirements, and furthermore finding the lowest common denominator based on them, would prove very helpful, even if it's just about validation and making people understand your lengthy proposal. I.e. a news reader that needs to sync content, but has an offline UI. Do you have a list collected somewhere? Sorry for not including the list in the initial email. It was long enough as it was so I decided to stop. Some of the use cases we discussed were: Small simple game The game consists of a set of static resources. A few HTML pages, like high score page, start page, in-game page, etc. A larger number of media resources. A few data resources which contain level metadata. Small amount of dynamic data being generated, such as progress on each level, high score, user info. In-game performance is critical, all resources must be guaranteed to be available locally once the game starts. Little need for network connectivity other than to update game resources whenever an update is available. Advanced game Same as simple game, but also downloads additional levels dynamically. Also wants to store game progress on servers so that it can be synced across devices. Wikipedia Top level page and its resources are made available offline. Application logic can enable additional pages to be made available offline. When such a page is made available offline both the page and any media resources that it uses needs to be cached. Doesn't need to be updated very aggressively, maybe only upon user request. Twitter A set of HTML templates that are used to create a UI for a database of tweets. The same data is visualized in several different ways, for example in the user's default tweet stream, in the page for an individual tweet, and in the conversation thread view. Downloading the actual tweet contents and metadata shouldn't need to happen multiple times in order to support the separate views. The URLs for watching individual tweets needs to be the same whether the user is using appcache or not so that linking to a tweet always works. It is very important that users are upgraded to the latest version of scripts and templates very quickly after they become available. The website likely will want to be able to check for updates on demand rather than relying on implementation logic. If the user is online but has appcached the website it should be able to use the cached version. This should be the case even if the user navigates to a tweet page for a tweet for which the user hasn't yet cached the tweet content or metadata. In this case only the tweet content and metadata should need to be downloaded and the cached templates should be used. If the user does not have twitter in the appcache and navigates to the URL for an individual tweet the website needs to be able to send a page which inlines resources such as CSS and JS files. This is important in order to avoid additional round trips. Webmail A lot of simularities with the twitter use case. The website is basically a UI for the database of emails. However its additionally important that the user can compose emails, including attach attachments, which are saved and synchronized once the user goes online. There are also other actions that the user might have taken while offline. This means that complicated conflict resolution might need to be done in order to synchronize with changes that has happened on the server. Blog reading Store the last X days of blog posts locally. Each blog post consists of the blog text as well as a few images. Other websites can link to individual posts. Each post contains a list of comments for the post. Adding comments should be possible even while offline. Once the user goes online it should be possible to submit these comments. Blog authoring Same as blog reading, but probably want to cache a larger set of posts. Repository of unpublished posts should be available for editing offline. Once the user goes online these edits are synced to server, and any posts that were published while offline are automatically published. Both adding and removing comments should be possible while offline. These changes too are published once user goes online. News website Front page with links to various articles. Each article as well as front page contains both text and images/media. Both front page and articles contains ads. A set of top articles are automatically cached and kept up-to-date. Potentially users can configure additional areas of interest which would cause additional articles from those areas to get cached. We should definitely put
Re: Collecting real world use cases (Was: Fixing appcache: a proposal to get us started)
On 19.04.13 00:01, Charles McCathie Nevile cha...@yandex-team.ru wrote: On Thu, 18 Apr 2013 19:19:17 +0300, Paul Bakaus pbak...@zynga.com wrote: Hi Jonas, Thanks for this I feel this is heading somewhere, finally! I still need to work on submitting my full feedback, but I'd like to mention this: Why did nobody so far in this thread include real world use cases? We submitted a few (they are not completely fleshed out but they are actual things we do) in the related thread http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0949.html Thanks both! I will dig through the links. Might be worth to collect them all into a list that's easily accessible so we can base any proposal or update to proposals on the UC's and validate against them. For a highly complex topic like this in particular, I would think that collecting a large number of user use cases, not only requirements, and furthermore finding the lowest common denominator based on them, would prove very helpful, even if it's just about validation and making people understand your lengthy proposal. I.e. a news reader that needs to sync content, but has an offline UI. Do you have a list collected somewhere? There are also use cases in the discussions of hosted apps in the SysApps WG - they are essentially working on the same problem. cheers Chaals Thanks! Paul On 26.03.13 16:02, Jonas Sicking jo...@sicking.cc wrote: Hi WebApps! Apologies in advance for a long email. This is a complex subject and I wanted to present a coherent proposal. Please don't be shy about starting separate threads when providing feedback. There has been a lot of debating about fixing appcache. Last year mozilla got a few people together mostly with the goal of understanding what the actual problems were. The notes from that meeting are available at [1]. Those discussions, and a few followup ones, has made it clear that there were a few big ticket items that we needed to fix: * The fact that master entries are automatically added to the cache works very poorly for a lot of developers. * Once a website is cached the user will only see the new version on second load, even if the user is online. This is good for performance but is a behavior many websites aren't willing to live with. * You have to tweak a comment of the manifest in order to trigger an update-check of the cached resources. * We need an escape hatch for people running into missing features in the appcache. I.e. a way for websites to use script to complement the set of behaviors supported by the appcache spec. * The fact that FALLBACK combined the hit network first, fall back to a cached resource and allow a cached resource to handle requests to a whole URL space behaviors is problematic since many times you want one and not the other. * People want to use appcache not just to make offline apps possible, but also make online apps fast. * There isn't enough ability to control the appcache through javascript. There are certainly other things that people have mentioned, but the above have been a reoccurring theme. Feel free to comment here if you have other issues with the current appcache, but it might be worth doing that as separate threads. I believe that some of these problems stem from a relatively small set of design problems: The appcache appears to be aimed at too simple applications. It works fine if the website you want to cache consists of a small set of static resources and otherwise only use features like IndexedDB or localStorage to manage dynamic data. But once an application uses server-side processing to dynamically generate resources based on query parameters or other parts of the URL, then it requires that you change the way that your application works. Another design aspect that appears to be causing problem is that appcache is optimized too heavily for minimizing the amount of typing that the author had to do. It attempts to help the author too much, for example by automatically adding master entries that link to an appcache but aren't enumerated in it. Or automatically adding the handler URLs from the FALLBACK section to the set of URLs to be automatically downloaded. The result is that the appcache contains too much magic. In theory an author can just type very little and the appcache will automatically do the right thing. However this magic is making it too hard for authors to understand what's going on. The result is that people don't use the appcache even if they might have needed to type very little to get it working. Implementations certainly hasn't helped here either, by not exposing the behind-the-scenes logic through debugging and developer tools. The fact that the appcache is aimed at simple applications is generally a good thing given that it's the first version. However the desire to make applications available offline, as well as make them faster when the user is online, has been so
Re: Collecting real world use cases (Was: Fixing appcache: a proposal to get us started)
On 4/18/13 12:19 PM, ext Paul Bakaus wrote: Do you have a list collected somewhere? Hi Paul, FYI, you might be able to scrape some UCs from the related workshop papers http://www.w3.org/2011/web-apps-ws/Papers. Virginie's paper includes a few (security-related) UCs http://www.w3.org/2011/web-apps-ws/papers/Gemalto.pdf. -AB
Re: Collecting real world use cases (Was: Fixing appcache: a proposal to get us started)
On Thu, 18 Apr 2013 19:19:17 +0300, Paul Bakaus pbak...@zynga.com wrote: Hi Jonas, Thanks for this I feel this is heading somewhere, finally! I still need to work on submitting my full feedback, but I'd like to mention this: Why did nobody so far in this thread include real world use cases? We submitted a few (they are not completely fleshed out but they are actual things we do) in the related thread http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0949.html For a highly complex topic like this in particular, I would think that collecting a large number of user use cases, not only requirements, and furthermore finding the lowest common denominator based on them, would prove very helpful, even if it's just about validation and making people understand your lengthy proposal. I.e. a news reader that needs to sync content, but has an offline UI. Do you have a list collected somewhere? There are also use cases in the discussions of hosted apps in the SysApps WG - they are essentially working on the same problem. cheers Chaals Thanks! Paul On 26.03.13 16:02, Jonas Sicking jo...@sicking.cc wrote: Hi WebApps! Apologies in advance for a long email. This is a complex subject and I wanted to present a coherent proposal. Please don't be shy about starting separate threads when providing feedback. There has been a lot of debating about fixing appcache. Last year mozilla got a few people together mostly with the goal of understanding what the actual problems were. The notes from that meeting are available at [1]. Those discussions, and a few followup ones, has made it clear that there were a few big ticket items that we needed to fix: * The fact that master entries are automatically added to the cache works very poorly for a lot of developers. * Once a website is cached the user will only see the new version on second load, even if the user is online. This is good for performance but is a behavior many websites aren't willing to live with. * You have to tweak a comment of the manifest in order to trigger an update-check of the cached resources. * We need an escape hatch for people running into missing features in the appcache. I.e. a way for websites to use script to complement the set of behaviors supported by the appcache spec. * The fact that FALLBACK combined the hit network first, fall back to a cached resource and allow a cached resource to handle requests to a whole URL space behaviors is problematic since many times you want one and not the other. * People want to use appcache not just to make offline apps possible, but also make online apps fast. * There isn't enough ability to control the appcache through javascript. There are certainly other things that people have mentioned, but the above have been a reoccurring theme. Feel free to comment here if you have other issues with the current appcache, but it might be worth doing that as separate threads. I believe that some of these problems stem from a relatively small set of design problems: The appcache appears to be aimed at too simple applications. It works fine if the website you want to cache consists of a small set of static resources and otherwise only use features like IndexedDB or localStorage to manage dynamic data. But once an application uses server-side processing to dynamically generate resources based on query parameters or other parts of the URL, then it requires that you change the way that your application works. Another design aspect that appears to be causing problem is that appcache is optimized too heavily for minimizing the amount of typing that the author had to do. It attempts to help the author too much, for example by automatically adding master entries that link to an appcache but aren't enumerated in it. Or automatically adding the handler URLs from the FALLBACK section to the set of URLs to be automatically downloaded. The result is that the appcache contains too much magic. In theory an author can just type very little and the appcache will automatically do the right thing. However this magic is making it too hard for authors to understand what's going on. The result is that people don't use the appcache even if they might have needed to type very little to get it working. Implementations certainly hasn't helped here either, by not exposing the behind-the-scenes logic through debugging and developer tools. The fact that the appcache is aimed at simple applications is generally a good thing given that it's the first version. However the desire to make applications available offline, as well as make them faster when the user is online, has been so great that people have wanted to use the appcache to solve a larger set of types of applications. So to some extent the appcache has been a victim of its own success. The other week a few of us at mozilla got together to discuss how to fix appcache. I.e. how to come up with a solution for the above mentioned problems. We came to a few
