It isn't flat-out evil, but it is, let's say, naughty.
The idea of the checkfriends feature (from the server's point of view, at least) is to reduce load: each checkfriends query is much lighter than preparing a complete friends page for the client. Plus, once there
are new items on the friends list, the client gives it a rest: it stops talking to the server until the user clicks on the indicator (which means something like "okay, I read my new entries; now look for newer ones"). This is what
the protocol says should happen (look for "new" in the Response section).
Now, this proposed feature (let's call it "thresholding"; and I've been a bit naughty myself for not crediting Sema for the idea in my main post) keeps on hitting the server even after one, two, or maybe more new entries have been noted. Of course, each of these hits is much lighter than one friends page load; but if it's on all day the total effect is not nice, too.
Of course, from the user's point of view, this *is* a nice feature. And if, from a usability perspective, it causes people to load their freinds page a bit less often, it's even worth it in terms of performance. But we need to think of sensible limits for this threshold--it make no sense for this to be really large.
(Something I was thinking about is that if thresholding is enabled, LogJam might quietly increase the checkfriends poll interval. Unfortunately, this isn't a very good thing to do, because the "new" value in the protocol doesn't really cound the number of new entries, but is rather just a flag that says whether any number of new entries have been added since the last check. So if the interval is too long, two friend's posts might get counted once.)
