Ajax Request Caching by Timestamp?

Hi everyone, first post here in the forum. I’m usually in #rubyonrails
on freenode.

I’ve been thinking about the various types of caching, and I was
wondering if its possible to have the server selectively send back data,
instead sending nothing ‘0’ if user has the newest data.

My example is a presence monitor, and it seems like the logic is:

  • Rails caches the ‘current user’ list fragment with a timestamp.
  • User requests a view that contains a periodic_updater to the current
    user list (and the updater passes the timestamp in its requests back to
    server)
  • the server compares it to the current timestamp on that fragment. if
    its identical. send back a 0/nochange notice. otherwise send back the
    newer data with its timestamp.
  • now further xhr requests from client contain the updated timestamp.

I’d like to know if anyones already attempted or thought of this before.

Thanks!
-zer0

Yes, or id.

Learn Ruby on Rails! Check out the FREE VIDS (for a limited time)
VIDEO #3 out NOW!
http://sensei.zenunit.com/

Julian L. wrote:

Yes, or id.

Not quite sure I understand your response.

After I posted I took a look over the cache api again. And one can use
regex to delete multiple fragments.

So for what I’m trying todo, it would be something like:

  • user requests index that has current_users partial, do a regex find
    for “current_users.*” (there should be only one)
  • the time stamp of that fragment is added to the params of a periodic
    updater.
  • each time the ajax request comes in, just do a straight find by name
    on the fragment. (ie current_users200804100923)
  • the fragment is found, send back nothing/0/nochange, (unless its been
    expired by someone logging in or logging out), in which case a new one
    is made, and time stamped.
  • rinse, repeat as needed =)

I’m really just thinking out loud and curious if anyone has tried
anything like this. I welcome your input.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs