NYCPHP Meetup

[David Mintz]

On Wed, Mar 4, 2009 at 2:53 PM, Jesse Callaway <bonsaime at gmail.com> wrote:

> On Wed, Mar 4, 2009 at 1:07 PM, David Mintz <vtbludgeon at gmail.com> wrote:
> >
> > 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
> >
> > _______________________________________________
> > New York PHP User Group Community Talk Mailing List
> > http://lists.nyphp.org/mailman/listinfo/talk
> >
> > http://www.nyphp.org/show_participation.php
> >
>
> Get a hash of the data returned from your remote request and remember
> it at the client. If you choose you can remember it on the server-side
> as well. But you might not have control over that, say if you are
> grabbing the weather from a provider.
> Anyway next time you get a response back check it against the
> remembered md5. If there's a match then don't update the document. I
> don't know if it's efficient or not, but it would cut down on
> redrawing the screen.
>


Understood. Thanks!


-- 
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/2f8ba765/attachment.html>