The only problem I see now with that approach is that a browser that
supports
both webm and mp4 videos would download both videos. It seems to me there
should be a way for the browser to determine duplicate content in the
manifest
file in the same way that it determines which video file to download
based on
the file-type.
Something like this might work better:
{'CACHE': [
{'file':'index.html','timestamp':'2013-11-27 00:00:00','type':'text/html'},
{'video': {'sources': [
{'file':'video.webm','timestamp':'2013-11-27
00:00:00','type':'video/webm'},
{'file':'video.mp4','timestamp':'2013-11-27
00:00:00','type':'video/mp4'}
]}
}
],
'NETWORK':'*',
'FALLBACK':[['online.jpg','offline.jpg'],['online.htm','offline.htm']],
'SETTINGS':'prefer-online'}
At least this way the appcache inherits the problem of video in HTML,
and the browser vendors can apply the present solution to the appcache.
-Eli
On 11/27/2013 10:38 PM, [email protected] wrote:
Json manifest seems a nice solution to me :-)
Send from my Samsung Galaxy Note II
El 28/11/2013 07:21, "eli" <[email protected]
<mailto:[email protected]>> escribió:
>> The web is server + client sides. Trying to "fix" issues
you have with
>> client technologies only (appcache, JavaScript, ...) will
always be a bad
>> choice.
>
> I disagree, Javascript and web browsers are becoming
powerful enough
> to delegate servers to their barebones, just offering storage or
> databases or specific web services, being able to delegate
all the
> operatibility to the client-side code. In the new web, web
servers are
> just plain ol' API
It's not that much a question of available power, it's just
operations that needs to be done before any file hit the device.
To be available offline, the device has to hit a server first,
then the appcache "magic" happens.
No reason the server couldn't prepare / select what to send to
the device: iOS won't support WebM anytime soon, there is no
reason to constantly ask iOS device the same info again &
again. That just makes no sense, and force devs to produce
device/os specific files (manifest) anyway.
And it's not AppCache job to do so. Its job is just make a web
document available offline + make updates simple & easy.
Example : Not being able to update one single file keeping the
others cached is a structural mistake. Sub-manifests sounds
like an over-engineered fix to me, just making things more
complicated for developers, browser vendors & for future
evolution of this specification.
Could the problems of not being able to update one single file in
the cache, and not sending WebM files to iOS devices, both be
solved by adding additional file info to the cache manifest?
For example, if the manifest were in JSON:
{'CACHE': [
{'file':'index.html','timestamp':'2013-11-27
00:00:00','expires':'2013-12-02 00:00:00','type':'text/html'},
{'file':'video.webm','timestamp':'2013-11-27
00:00:00','expires':'2013-12-02 00:00:00','type':'video/webm'},
{'file':'video.mp4','timestamp':'2013-11-27
00:00:00','expires':'2013-12-02 00:00:00','type':'video/mp4'}
],
'NETWORK':'*',
'FALLBACK':[['online.jpg','offline.jpg'],['online.htm','offline.htm']],
'SETTINGS':'prefer-online'}
This way, a browser can compare a file's timestamp in the newly
downloaded manifest to the one in its stored manifest to determine
whether or not to download a new version. And an iOS device could
ignore 'video/webm' file-types.
-Eli
> --
> "Si quieres viajar alrededor del mundo y ser invitado a
hablar en un
> monton de sitios diferentes, simplemente escribe un sistema
operativo
> Unix."
> – Linus Tordvals, creador del sistema operativo Linux
