NYCPHP Meetup

[David Mintz]

On Wed, Mar 4, 2009 at 12:17 PM, John Campbell <jcampbell1 at gmail.com> wrote:

> >> Use AJAX instead to refresh just the part of the page that needs
> >> refreshing. If it's a fair chunk of information, you set a "version"
> >> on the server so the AJAX call just checks the current version vs it's
> >> version. If it's different, then you refresh the content. If it's not
> >> different, no need to refresh anything and you only did a light weight
> >> server call, so you could do it every 15 seconds.
> >
> > Forgive me, I don't quite understand *how* you would set the version
> > information on the server in order to compare.
>
> In many cases, you can get away with using timestamps.  If you have
> update_at columns, then you can compare the timestamps.  In theory,
> there are problems with this method (such as updates that happen
> during the same second), but in practice, it works quite well.
>


Still not sure I get it -- I am competing the for Slowest Mind of the Year
Award.

The users are looking at a set of database rows. The table does have
last-modified and creation-datetime columns. Saving the current set's
maximum last-update and/or created value in the client, and then checking
against the server by running an Ajax request to a server-side script that
in turn queries the db to see if anything has changed... seems like almost
as much overhead as just reloading unconditionally. Indeed more in those
instances where you query to check if something changed, then do another
query to load the data because something did change.

And by "change" I mean in the dataset they are looking at, a row may have
been either created, updated or deleted since they last loaded the view. So
last-modified values would not inform you about deletions.

I don't understand the md5() technique either. I mean, I know about md5()
but don't see how you would use it efficiently for this purpose.

-- 
David Mintz
http://davidmintz.org/

The subtle source is clear and bright
The tributary streams flow through the darkness
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20090304/c41ea165/attachment.html>