Le 25 nov. 2013 à 17:27, James Greene <[email protected]> a écrit :
> > Your manifest file should be dynamically generated by your server, based on > > what you know about the user's browser. > > Now you have one single manifest file which is easier for updates, + > > server-side language comments so documentation is easy. > > 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 would contest this point as now you're suggesting that the "right" thing to > do is to force everyone to maintain custom browser detection libraries on > their servers again in order to guess what the browser's capabilities are. > As we know from much experience with this technique already, it is brittle > and must be constantly monitored and updated as new browser versions are > released. Why not attempt to give the browser-side manifest functionality > the ability to "feature test" for file support instead? Then the browsers can > be the trusted source instead of everyone having to create new divergent > browser file support inference hacks. > > Sincerely, > James Greene I'm not rejecting anything or trying to state something is good or bad. Just like i'm not rejecting the server side as a devil to kill. Current AppCache state is not THAT bad for static document cache. It's pretty much 100% client-side, and with a little bit of extra work to fix how it handles files updates, it might be ok, still easy to deal with. (file by file update without complete manifest swip, grouped files versionning, end of validity datetime, …) Then for further / more complicate / specific use cases, some server-side scripts might be needed. And trying to do everything only from the client-side is a bad choice, just like previous things we did thinking server-side only was a bad choice too. Remi
