Re: What is the purpose of 'appcache_path' field?


On 23 avr. 2013, at 07:53, Long, Xiang wrote:

> Hi,
> I think the "appcache_paths" filed in manifest provides a possibility for runtime to handle hosted app's cache w/o parsing the HTML file.

The cost looks too high to me to let the developer manage this problem himself on day basis, while parsing the root tag of html files while installing seems quite reasonable

> For example, download cache in app installation time, or notify user when a cache update is available.

I think that listing the HTML files to be parsed in the manifest could solve this and would be more acceptable for a developer

ex:

checkForAppCache: [
    '/main.html',
    '/special.html'
]

It would be part of the process when adding or removing a module, and such process is already done by package developers when they list dependencies


> For multiple cache manifest paths, is it possible for web developers to use a same cache manifest for different pages? Like:
> /main.html
> <html manifest="myapp.manifest">
> ...
> /special.html
> <html manifest="myapp.manifest">
> ...

It is technically possible to reference the same myapp.manifest and could be ok when such html files only belong to this app
But it is not imaginable for an HTML module shared among different apps

You can imagine special receiving messages to process from main with specific UI interactions. If special is updated and requires changes in its appcache, it is hard to ask to all the dependent apps to update their own appcache instead.


>
> Regards,
> Long Xiang
>
>>



Alexandre Morgaut
Wakanda Community Manager

4D SAS
60, rue d'Alsace
92110 Clichy
France

Standard : +33 1 40 87 92 00
Email :    Alexandre.Morgaut@4d.com
Web :      www.4D.com


-----Original Message-----
>> From: Alexandre Morgaut [mailto:Alexandre.Morgaut@4d.com]
>> Sent: Tuesday, April 23, 2013 12:03 AM
>> To: Min, Hongbo
>> Cc: Marcos Caceres (w3c@marcosc.com); public-sysapps@w3.org
>> Subject: Re: What is the purpose of 'appcache_path' field?
>>
>> Hi,
>>
>> I'm also still not comfortable on this point, partly because it means one only
>> appcache file per app / package
>>
>> The appcache manifest, when defined per page as via the html manifest
>> attribute
>> (http://www.w3.org/TR/html5/semantics.html#attr-html-manifest) allows
>> more modular handling of the appcache properties of a web application.
>>
>> Not all Web applications, even mobile ones, are single page applications.
>> Think a page as an application interface module.
>>
>> If we might fix the issue by replacing the string format by
>>
>> 1 - an array of objects as
>>
>> appcache_paths: [
>>     {"page": "/main.html", "manifest": "/main.appcache"},
>>     {"page": "/special.html", "manifest": "/special.appcache"}
>> ]
>>
>> 2 - a object in which the keys are the page paths
>>
>> appcache_paths: {
>>     "/main.html": "/main.appcache",
>>     "/special.html": "/special.appcache"
>> }
>>
>> I still have issues when working on an interface organized as a git
>> submodule:
>> - any update to this application module will have to be pushed to the
>> manifest of the main application repository;
>> - such updates will have to take care of the main web app repository
>> merges
>> - the module is definitely not testable in standalone mode
>>
>> Worst, if this git submodule is used by different web apps, it becomes
>> hard  to push updates to all apps using it.
>>
>>
>> On 22 avr. 2013, at 14:33, Min, Hongbo wrote:
>>
>>
>> Marcos,
>>
>> I noticed that the manifest JSON is also providing an ‘appcache_path’
>> member. I am wondering its purpose since web app can specify the appcache
>> manifest URL in the web page like:
>>
>> <html manifest=”example.appcache”>
>> …
>> </html>
>>
>> Why not use the manifest attribute in html tag and re-invent a new one?
>>
>>
>> Thanks
>> Hongbo
>>
>>
>>
>> Alexandre Morgaut
>> Wakanda Community Manager
>>
>> Email :
>> Alexandre.Morgaut@4d.com
>> Web :
>> www.4D.com
>>
>>
>> 4D SAS
>> 60, rue d'Alsace
>> 92110 Clichy - France
>>
>> Standard :
>> +33 1 40 87 92 00
>>
>>
>>
>>
>>

Received on Tuesday, 23 April 2013 09:33:05 UTC