On Thu, 28 Nov 2013 16:38:55 +1000, [email protected] <[email protected]>
wrote:
Json manifest seems a nice solution to me :-)
Blergh! :-)
More to the point, it seems that the approach of ServiceWorker discussed
at the TPAC meeting, and based on Alex Russell's proposal which is
unfortunately lacking an actual spec, is getting considerable traction as
the path to follow for fixing appcache.
It would be useful to get a sense of whether people think we should do
something else.
cheers
Chaals
Send from my Samsung Galaxy Note II
El 28/11/2013 07:21, "eli" <[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
--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
[email protected] Find more at http://yandex.com
