Server-side Caching

[nimbupani]

Was talking to @addyosmani that we would need some sort of server-side caching. A simple hash of the requested UA & request options might be sufficient?

Anyone knows enough PHP to pick this up :)

[dmolsen]

i'm taking a shot at this. is the API doc up-to-date? i've noticed a discrepancy between it and the filter_options function. this sounds like a pretty straightforward feature.

[nimbupani]

Likely there is a discrepancy, I noted them down in haste in the wiki :) Please be updating if you find more options. I would love to have caching up and running!

[dmolsen]

I worked on this last night but I realized I made it too simple & it's only a file system cache. It doesn't take into account that your output will change based on new browsers. I'll continue to work on it.

At the end of the day I'm not really sure it's going to improve all that much. It seems like a better option would be to store data on the client. For any particular user-agent if they failed once they'll always fail. The only thing that will change from their perspective is the list of browsers that are compatible with the feature they want to support. And those browsers don't come out every day.

It might make more sense to push the content retrieved via JS from your API into a cookie w/ a short time out (say 12 hours) so that your API only gets hit twice a day for a particular client. Something similar could be done for server-side clients using your service. For example, I'd love to integrate your API with my project, Detector, but there's no need to request data from you guys on every page request. I don't see why the Modernizr plugin couldn't be upgraded to check the availability of a cookie first. It can work similar to the server-side cache.

If that's of interest I can address the client-side issue too.

[nimbupani]

I think that is a great idea. But we need to be careful here as UAs keep updating their versions so our local data might be out of date etc so need some thorough checks.