[whatwg] Appcache feedback (various threads)

[Ian Hickson]

On Mon, 19 Apr 2010, Alexey Proskuryakov wrote:
>
> There seems to be a race condition in how application cache groups are 
> marked obsolete. Consider the following scenario:
> 
> 1. A document is loaded from server, an appcache is fully created.
> 2. Appcache update is initiated (e.g. by calling
> DOMApplicationCache.update()).
> 3. A new document is loaded, whose main resource comes from this appcache.
> 4. Update started at step 2 fails, because manifest is 404. Appcache is marked
> obsolete.
> 5. The new document is being parsed, and the parser finds manifest
> declaration.
> 6. Parser invokes application cache selection algorithm.
> 7. The application cache selection algorithm associates the document with
> obsolete appcache, because it was loaded from this appcache.
> 
> But at the same time, according to downloading or updating an application
> cache algorithm, "the [obsolete] cache group no longer exists for any purpose
> other than processing of Document objects already associated with an
> application cache in the cache group.
> 
> Which part of the spec wins?

Apparently the spec doesn't win. :-(

Fixed.


On Tue, 18 May 2010, Patrick Mueller wrote:
>
> under 6.6.4 "Downloading or updating an application cache"
> under "The application cache download process steps are as follows:"
> under step 17: "The application cache download process steps are as
> follows:"
> under sub-step 2: "For each cache host associated with an application cache"
> 
> Discussion about using "lengthComputable", "total", and "loaded"
> attributes of the ProgressEvent interface.
> 
> There is a new draft of the Progress events spec here:
> 
>    http://dev.w3.org/2006/webapi/progress/Progress.html
> 
> In this draft, two new attributes of the ProgressEvent interface have
> been added: "loadedItems" and "totalItems". These attributes might be
> better suited to be used rather than the "total" and "loaded" attributes.
> 
> Same for step 18, which indicates a final ProgressEvent should be sent
> at the completion of the cache download process.

I considered changing this, but I'm not convinced we should add 
loadedItems and totalItems to the progress events spec really. I spoke to 
the WebKit guys and they suggested not changing this, since there didn't 
seem to be much advantage to it and it would break back-compat.


On Wed, 19 May 2010, Patrick Mueller wrote:
>
> I've been playing with application cache for a while now, and found the 
> diagnostic information available to be sorely lacking.
> 
> For example, to diagnose user-land errors that occur when using 
> appcache, this is the only practical tool I have at my disposal:
> 
>    tail -f /var/log/apache2/access_log /var/log/apache2/error_log
> 
> I'd like to be able to get the following information:
> 
> - during "progress" events, as identified in step 17 of the application
> cache download process steps in 6.6.4  "Downloading or updating an
> application cache"), I'd like to have the URL of the resource that
> is about to be downloaded.  The "progress" event from step 18 (
> indicating all resources have been downloaded) doesn't need this.

What do you need this for?


> - for all error conditions, some indication of WHAT error occurred.
> Presumably an error code.  If the error involved a particular resource,
> I'd like the URL of the resource as well.
> 
> I'm not sure what the best mechanisms might be to provide this info:
> 
> - extend the events used to add this information
> 
> - provide this information in the ApplicationCache interface -
> lastErrorCode, lastResourceDownloaded, etc
> 
> - define a new object as the target for these events (currently
> undefined,or at least not clear to me), and add that info to the target
> 
> - something else

Could you describe how you would use this information? What would you do 
differently based on this information?


On Thu, 3 Jun 2010, Daniel Glazman wrote:
> 
> I noticed the Application Cache does not allow to remove a single cached 
> web application from the cache. Is that on purpose?

>From the author perspective: just remove the manifest (return 404 or 410 
for its URL) and the next time the cache is updated, it'll be dropped.


> I am under the impression the cache is here more an offline storage for 
> webapps than a normal cache, and that in the long run browsers will have 
> to implement an "Offline Web Apps" manager. Since the user is supposedly 
> already provided with a dialog asking permission to make a webapp 
> available offline, it makes sense to give him/her a way to remove a 
> single application from the cache.

I don't think there should be such a dialog, but if there is, the user 
agent can definitely also provide one to remove appcaches.


On Thu, 3 Jun 2010, Peter Beverloo wrote:
> 
> The API does not state a way allowing an application to remove itself 
> from the cache, which could be desirable for web authors. If there's 
> interest for such an addition I'm willing to make a proposal, as it 
> isn't hard to think about use-cases for such a feature.

If this is something that people want, we can definitely add it in a 
future version. It'll be clear if people want it because some will fake it 
with returning 410s. If nobody does, then clearly they don't want it 
enough for it to be worth adding to the API. :-)


On Mon, 19 Jul 2010, Joseph Pecoraro wrote:
>
> Application Caches right now do not have any storage limitations. This 
> has clear issues when used on devices with limited storage capacity. 
> Other programmatic client side storages do have quotas mentioned in 
> their specs or in practice:
> 
>   - Web Storage StorageAreas (localStorage and sessionStorage)
>     QUOTA_EXCEEDED_ERR exception when reaching their quota.
>     http://dev.w3.org/html5/webstorage/
> 
>   - Web SQL Databases
>     QUOTA_EXCEEDED_ERR exception when reaching its quota.
>     http://dev.w3.org/html5/webdatabase/
> 
>   - Indexed DB
>     RECOVERABLE_ERR exception when "... or the storage quota was reached ... "
>     http://www.w3.org/TR/IndexedDB/
> 
>   - Cookies
>     "Minimum size" a client should support was stated in the HTTP Spec as
>     4kb, so that is often quoted and respected as the size to not exceed.
> 
> These quotas are often global, some kind of user setting, or are 
> per-origin. Application Caches are missing such a quota.
> 
> The entire "Disk Space" section of Web SQL Databases could equally apply 
> to Application Caches: http://dev.w3.org/html5/webdatabase/#disk-space

I suppose that's not unreasonable. I've added a similar section to the 
appcache section.


> The manifest file specifies the resources to cache, and the user agent 
> caches each resource. There may be multiple application caches for a 
> single domain. Be it through multiple Application Hosts, or multiple 
> Application Groups (unique by their manifest URL, but not domain).
> 
> A user agent can do as it pleases, but the only real limit is the 
> remaining space of the file system. If a resource cannot be cached 
> because there is no more space left, there is no way around that.
> 
> The likely behavior would be the user agent emits an "error" event. 
> However, storage limits are not specified in the spec as an error 
> condition: 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#event-appcache-error

In general the specification does not specify behaviour in handling 
constraints of the operating environment (e.g. out of memory, out of disk 
space). I've added some generic handling for this. We can add more 
detailed error reporting in a future version if there are good reasons to 
do this.


On Thu, 29 Jul 2010, Zi Bin Cheah wrote:
>
> Why did we want to use a new file extension .manifest in appcache.

You can use any extension you like. I just listed .manifest because the 
registration template for the MIME type asked for one.


> Wouldn't it be better to to just use a XML file instead, one benefit is 
> eliminating the requirement of specifying MIME type in .htaccess.

XML files are not as simple.


On Thu, 29 Jul 2010, Anne van Kesteren wrote:
> 
> XML would be much too complex for what is needed. We could possibly 
> remove the media type check and resort to using the "CACHE MANIFEST" 
> identifier (i.e. "sniffing"), but the HTTP gods will get angry.

Yeah, that's pretty much the way it is.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'