Re: Fixing appcache: a proposal to get us started

>> 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.


> -- 
> "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

Received on Monday, 25 November 2013 15:11:33 UTC