Make main page do like small pages February 11, 2011 2:27 AM   Subscribe

Pony request: I like the way new comments are reflected in the document title. Could we do the same for the main page?

I mean, I've got way too many tabs open, so I like the way the page occasionally polls to check if there are new comments and when there are, the page updates the title of document to reflect the number of new comments. That way I can leave an open thread open in a tab and see if there are new comments before I bother to click on the tab.

I want this for the main page. I want to leave any Metafilter page, especially the main page, open in a tab and have the page occasionally tell me if there are new posts.
posted by twoleftfeet to Feature Requests at 2:27 AM (71 comments total) 1 user marked this as a favorite

Yes. Yes. Yes.
posted by artof.mulata at 2:35 AM on February 11, 2011


I would imagine that they want to first finish rolling out the ajax comments to all sites before even considering anything else.
posted by Rhomboid at 3:16 AM on February 11, 2011


There isn't any difference between doing an AJAX update on a DIV at the end of the page and doing the same thing for the DIV at the top of the page. There's no difference in the technology. So a slow "rolling out" is unnecessarily conservative. Shit, this kind of update is beginner stuff nowadays.

That said, most websites should do this. But how many do?
posted by twoleftfeet at 3:26 AM on February 11, 2011 [1 favorite]


I don't. =(

I wish it came after the title of the FPP, at least. "Mountain Gorillas (2) | MetaFilter"

The way it is now, it makes it harder to read the title if I have a number of tabs open.
posted by Eideteker at 3:53 AM on February 11, 2011 [5 favorites]


Maybe they want to gauge the full site-wide effect of thousands of idle browsers each with multiple tabs each constantly hitting the site every 20 seconds will affect the health and load on the server. Maybe they want to thoroughly measure that before pondering if multiplying that increase is really worth it for the marginal gain of not having to refresh the main posts page which unlike thread pages doesn't grow out of control in length and doesn't have ongoing conversations. Maybe they want to follow the principle of letting one change stabilize before making another. Maybe they want to fully hear user comments about the change from people that don't visit the blue (a not insignificant portion of the userbase, btw.)

The fact that changes to this site are thoroughly discussed and carefully implemented is a feature not a bug.
posted by Rhomboid at 4:04 AM on February 11, 2011 [6 favorites]


constantly hitting the site every 20 seconds

That would be a very naive way to implement an update schedule. Javascript can tell if you have focus or not. There's no need to update without focus. Even if the page were left focused you could update on an exponentially decreasing update cycle.

The bandwidth for an update is on the order of magnitude of a ping, so it needn't hit the server non-trivially.
posted by twoleftfeet at 4:12 AM on February 11, 2011 [1 favorite]


There isn't any difference between doing an AJAX update on a DIV at the end of the page and doing the same thing for the DIV at the top of the page. There's no difference in the technology. So a slow "rolling out" is unnecessarily conservative. Shit, this kind of update is beginner stuff nowadays.

Yes, I've often found that telling people how do to their job does wonders for the conversation.
posted by Brandon Blatcher at 4:19 AM on February 11, 2011 [4 favorites]


> There's no need to update without focus.

Pssst. The request was to update specifically when the Mefi tab isn't in focus.
posted by bjrn at 4:20 AM on February 11, 2011


The point of the Ajax "new comments" update is that manually refreshing the page a) takes you to the top of the page not the bottom where the new comments are, and b) massive threads (e.g. the Egypt one) takes ages to reload. The Ajax thingy keeps you at the bottom of the page (no scrolling) and only loads the new comments, not the whole thread (faster loading). The main page has neither of these problems, since new posts appear at the top of the page anyway, and there is always a limited number of posts on the main page.

So the only advantage this would offer is the "(1)" in the browser tab, but new MeFi posts are not like participating in a thread where the next comment is the next part of an ongoing conversation.
posted by EndsOfInvention at 4:26 AM on February 11, 2011


The request was to update specifically when the Mefi tab isn't in focus.

You're right. My bad.

But I don't see how the server load is any different if I leave an unfocused small page open in tab or if I leave the unfocused main page open in a tab.

The Ajax thingy keeps you at the bottom of the page (no scrolling) and only loads the new comments,

Yeah, but you can do that at the top just as easily. Why should I have to reload the main page just to see if there's anything new? Never mind the server hit, why should I have to click on a tab and hit Reload if there's nothing new?

My RSS reader can hit Metafilter a zillion times, and I have yet to crash Metafilter. Really, it's not going to be that heavy a load.
posted by twoleftfeet at 4:37 AM on February 11, 2011


you could update on an exponentially decreasing update cycle.

That's what it does kind of
posted by specialagentwebb at 5:06 AM on February 11, 2011


The bandwidth for an update is on the order of magnitude of a ping, so it needn't hit the server non-trivially.

A ping packet is handled directly by the kernel's TCP/IP stack sending a single stateless response packet without a context switch; this takes very little processing and is quite efficient. Responding to an AJAX query involves: establishing a TCP session; receiving the HTTP request and parsing the request headers; finding the appropriate handler for the request; loading, parsing, and compiling a coldfusion script; connecting to a database; executing a query; waiting for the response as the database reads its indexes and tables to fulfill the query; parsing the SQL result; forming a HTML response in the form of a proper HTTP message; sending that response; and closing down the connection. This involves the co-operation of Apache, CF, MySQL, and the TCP/IP stack and involves many context switches. It is orders of magnitude more work than a ping reply. You can easily bring a site down by inundating it with HTTP requests but you can rarely do the same with pings. Bandwidth is not the relevant factor here.
posted by Rhomboid at 5:07 AM on February 11, 2011 [2 favorites]


My RSS reader can hit Metafilter a zillion times, and I have yet to crash Metafilter. Really, it's not going to be that heavy a load.

Sigh. A) the main feeds are offloaded by feedburner so Metafilter servers don't have to handle them at all. B) not everyone that uses the site uses RSS, but everyone that uses the site will trigger ajax checking. C) the RSS feeds specify a TTL/minimum update time of 60 minutes, so your RSS reader at most hits the site once an hour. If you have 10 busy tabs open for an hour that's potentially 1800 hits vs. the one RSS hit.
posted by Rhomboid at 5:12 AM on February 11, 2011 [1 favorite]


I still don't understand why it's more difficult to do this with the main page than with the small pages.

It's certainly less useful for me to have to reload the main page just to see if anything has changed.
posted by twoleftfeet at 5:13 AM on February 11, 2011


By the way, I've reloaded this page a half dozen times just to see if there was any progress... when there wasn't. I don't think that's the best way to do things on either end.
posted by twoleftfeet at 5:20 AM on February 11, 2011


Yeah, but you can do that at the top just as easily.

My point was not that it is hard to do it at the top, my point was why bother doing it at the top? The point of loading the comments at the bottom is to save you from scrolling down. If you reload the front page the new stuff is right there at the top anyway so you don't need to scroll.
posted by EndsOfInvention at 5:27 AM on February 11, 2011


Responding to an AJAX query involves: establishing a TCP session; receiving the HTTP request and parsing the request headers; finding the appropriate handler for the request; loading, parsing, and compiling a coldfusion script; connecting to a database; executing a query; waiting for the response as the database reads its indexes and tables to fulfill the query; parsing the SQL result;

And that's an absolutely ridiculous way to do things for the main page. You don't need SQL to tell you if there's a new post.
posted by twoleftfeet at 5:28 AM on February 11, 2011


If you reload the front page the new stuff is right there at the top anyway

I don't want to have to reload the front page. It's off in a different tab. I want to be able to look at the tab and get an indicator that there is something there worth looking at.

Somebody tell me why it's more difficult to do this for the main page than it is for the small pages.
posted by twoleftfeet at 5:31 AM on February 11, 2011


I need this feature, if only to avoid the heartbreak and frustration of reloading the front page and discovering that there are no new posts. If I'm going to go to the effort of moving my hand over to the mouse, shifting the cursor to the upper-left and then clicking, there had damn well better be something new to read.
posted by Pater Aletheias at 5:51 AM on February 11, 2011 [8 favorites]


twoleftfeet, are you serious? Why don't you chill out and wait for a mod response instead of continuing to pile on about how easy and trivial this would be, and about how doing anything else is stupid? Do you have any idea how you're coming off right now? Asking for new features on a website shouldn't be your chance to show off what an unpleasant person you can be.
posted by SpiffyRob at 6:00 AM on February 11, 2011 [7 favorites]


Asking for new features on a website shouldn't be your chance to show off what an unpleasant person you can be.

Yeah, I think your idea is a good one, twoleftfeet, but you are not doing a good job of making your case here.
posted by Rock Steady at 6:05 AM on February 11, 2011


If you just want the page to ping to see if a document has changed, you could do this:
function ping(message) {
var client = new XMLHttpRequest();
client.open("POST", "/ping");
client.send(message);
}

Or if you want to check the status of a document on the server:

function fetchStatus(address) {
var client = new XMLHttpRequest();
client.onreadystatechange = function() {
// in case of network errors this might not give reliable results
if(this.readyState == 4)
returnStatus(this.status);
}
client.open("HEAD", address);
client.send();
}
And parse for a 304. It's really not anymore resource-intensive.
posted by twoleftfeet at 6:07 AM on February 11, 2011


Don't listen to them twoleftfeet, you're totally and completely right, and since this is the internet, it's your moral duty to convince everyone of that.
posted by Brandon Blatcher at 6:07 AM on February 11, 2011 [4 favorites]


Asking for new features on a website shouldn't be your chance to show off what an unpleasant person you can be.

My experience has been that any request for a new feature, however laudable in principle, is always greeted with derision. So perhaps the unpleasantness has been unjustly assumed.
posted by twoleftfeet at 6:11 AM on February 11, 2011


Any code that you are not personally writing is trivial.
posted by Artw at 6:15 AM on February 11, 2011 [14 favorites]


Don't. Asking for a feature is fine. "Explaining" how it is trival beginner's stuff is clueless and rude. Do you really think pb or mathowie need your help coding their site? Don't walk into a pro's house and start explaining to them the fundamentals of their game.
posted by Babblesort at 6:28 AM on February 11, 2011 [1 favorite]


This is an interesting request, but in my usage, this is what Google Reader is for.
posted by mysterpigg at 6:35 AM on February 11, 2011 [1 favorite]


Any code that you are not personally writing is trivial.

Well, I can correct for the network errors that might not give reliable results (as per the comment in the W3C example code), if you want me to, Artw. It's not trivial.

I'm still waiting for somebody to explain why it's not possible to do the same thing for the main page that is already happening a zillion times a day for the small pages.

Don't walk into a pro's house and start explaining to them the fundamentals of their game.

The closest to "explaining to them the fundamentals of their game" I've come is to correct an earlier comment by someone else that "their game" necessarily required SQL queries to determine if a page has been modified. That, and my statement that this kind of update is beginner stuff nowadays. But it is. It really is.
posted by twoleftfeet at 6:38 AM on February 11, 2011 [1 favorite]


My experience has been that any request for a new feature, however laudable in principle, is always greeted with derision. So perhaps the unpleasantness has been unjustly assumed.

I hear where you're coming from. MeTa isn't always the friendliest place. But look over your input to the thread this far. Do you think you're helping that, or making it worse? I'm not trying to be snarky, and I am venting a little bit, because I have to deal with this sort of thing at work all the time. But look: You clearly know quite a bit about coding, so I'm going to assume you've got some professional experience. Put yourself in pb's shoes. Which do you think he'd rather wake up this morning to find: A simple, clear request, which your original post was, or 10 comments of taking on all comers for anyone who dares to discuss it?
posted by SpiffyRob at 6:38 AM on February 11, 2011


And:

I'm still waiting for somebody to explain why it's not possible to do the same thing for the main page that is already happening a zillion times a day for the small pages.

Excellent plan. I strongly, strongly suggest that further waiting happen with your hands off of the keyboard, at least in this thread.
posted by SpiffyRob at 6:42 AM on February 11, 2011 [3 favorites]


I'm going to suggest they do it to Recent Activity, and give pb a heart attack.
posted by Artw at 6:44 AM on February 11, 2011


You don't need SQL to tell you if there's a new post.

How exactly do you propose it would be done then? Your ajax example is totally wrong and irrelevant because it assumes that the front page is a static document which it is not; it is a dynamic page. You will never, ever get a 304. This whole site is dynamic.
posted by Rhomboid at 6:45 AM on February 11, 2011


I know I'm in the minority here, and may be labeled as a pony-hater, but those of us attempting to surf on the DL don't really need more auto refresh.

Wish I could opt out of the comment refresh...
posted by JoanArkham at 6:48 AM on February 11, 2011


I'm still waiting for somebody to explain why it's not possible to do the same thing for the main page that is already happening a zillion times a day for the small pages.

This is good, you're doing an excellent job of making a polite request and then patiently waiting for an answer the actual programmers of the site.
posted by Brandon Blatcher at 6:49 AM on February 11, 2011


Put yourself in pb's shoes.

If pb is overwhelmed by comments made on some Metafilter thread then pb doesn't know Metafilter. Since pb knows Metafilter, he is not overwhelmed.

But I take your point to do further waiting with my hands off the keyboard.

It's a reasonable feature, I think. I'm sorry if my presentation made it seem less so.
posted by twoleftfeet at 6:49 AM on February 11, 2011


Artw: "I'm going to suggest they do it to Recent Activity, and give pb a heart attack"

I would actually like this.
posted by Memo at 6:51 AM on February 11, 2011


It's a reasonable feature, I think. I'm sorry if my presentation made it seem less so.

And I'm sorry if I came off as harsh. I like your idea.
posted by SpiffyRob at 6:55 AM on February 11, 2011


It's a reasonable feature, I think. I'm sorry if my presentation made it seem less so.

Changes to the UI involve both making sure we can implement them across every browser a MeFite is likely to use as making sure that this is a change that most MeFites would either like or be able to turn off. We're not Gawker, we can't just redesign and then tell people to suck it.

So making this change if I understand correctly would, if you have metafilter.com open, poll the page periodically to see whether there are new comments and then provide an aggregate number of new comments to all the posts that are on the front page, correct? I can see how that would be useful. I can also see how it would be big and complicated to put together and maybe not the best use of pb's time. So, we can wait til the guys are up and see what they have to say about this. It wouldn't solve a problem for me personally but that doesn't mean it might not be a useful feature.
posted by jessamyn (staff) at 7:17 AM on February 11, 2011


Not only they are both left ones, that's a bit odd, but being able to fit them both in there at once is really amazing.
posted by Wolfdog at 7:20 AM on February 11, 2011 [1 favorite]


We're not Gawker, we can't just redesign and then tell people to suck it.

I like to think that they all hate the redesign too, but that Nick Denton has a machinegun and a Scarface size pile of cocaine on his desk so everyone is afraid to say anything.
posted by Artw at 7:25 AM on February 11, 2011 [1 favorite]


So making this change if I understand correctly would, if you have metafilter.com open, poll the page periodically to see whether there are new comments and then provide an aggregate number of new comments to all the posts that are on the front page, correct?

No, I think they wanted to see when there were new MetaFilter posts, not new comments.
posted by EndsOfInvention at 7:26 AM on February 11, 2011 [1 favorite]


This drama is my fault. I asked for this previously - I should have made a thread about it sans grar. My bad.

No, I think they wanted to see when there were new MetaFilter posts, not new comments.

That's what I envisioned, at least.
posted by cashman at 7:33 AM on February 11, 2011


we can't just redesign and then tell people to suck it

I made the SAME comment in that circumcision thread, but it got deleted.
posted by the quidnunc kid at 8:03 AM on February 11, 2011 [6 favorites]


It's an interesting feature idea. We can certainly talk about it; if we're talking about polling for posts and not comments, it doesn't sound like it'd have to be a nutty drain considering how well the thread pilot is going, but I know better than to speak for pb on this stuff.

That said, asking is great; stamping your feet repeatedly in a thread and defying people to explain to you why this isn't perfect and declaring our attempts to roll stuff out gently to be misguided instead is all pretty not-great. I dig that you're excited about the idea, but as far as behavior goes that's pretty crappy to wake up to.

If pb is overwhelmed by comments made on some Metafilter thread then pb doesn't know Metafilter. Since pb knows Metafilter, he is not overwhelmed.

pb knows what site he works for, and he's made of reasonably stern stuff, but part of how we as a team express our appreciation for all the awesome work he does on the coding side of the site is making it pretty much explicit that it's not his job to deal with a lot of the messy human-interaction stuff that's more for me and jess to slog through.

Threads where feature requests take on weird pushy dynamics are an odd middle-ground there, because it's kind of like someone demanding that he shows up and does what's not his job, which is pretty counter-productive if the goal is to let him actually do some implementation work. He'll probably show up and be polite, but that's more than he should have to do. Eesh.
posted by cortex (staff) at 8:12 AM on February 11, 2011 [8 favorites]


Good morning! This sounds like a reasonable request technically, and it's something we're considering. I've had a few people send me MeFi Mail asking for the same thing and it was mentioned in the other thread, so it's definitely in the air.

The ease of implementation factors into our decision about features, but it's not the sole consideration. (As much as I wish it was—kidding!) It's not even at the top. We do have to consider it because Matt and I are the only people who write code for the site. So we have limited resources which means we have to balance a long list of new features to develop with ongoing maintenance. Our top concern with any feature is how it will affect site culture. That's not always an easy question to answer. MetaTalk discussions help guide us here, we all take time to think about potential changes, and then we discuss them. Matt has the final word.

Even if I was extremely gung ho about this feature, it would still take time to go through our process so I can't give you an answer right away. I think discussing it here is a great first step.
posted by pb (staff) at 8:14 AM on February 11, 2011 [1 favorite]


twoleftfeet, you might want to try your code out in a greasemonkey script to see if it's possible. Outside of that, I have to say that the counts changing the titles are both super useful and highly contentious, and I'd say based on feedback about 2/3 of users love it and 1/3 hate it. Adding it to the front page for new post notifications is not something we'd likely do, since it's not something that happens commonly (front page of mefi probably sees one post per hour on avg).

Since it's not a regular common update kind of thing (a comment page is being updated much, much more often in smaller chunks of time), it'd be a big load on the server to poll constantly to check for new posts when in reality people catching new posts on the front page would be lucking into that one new post per hour. We'd also have to stretch out our polling timer to allow a tab to be open for hours and hours and keep checking.

This seems like something more in line with greasemonkey, if you can figure out a way to do it without SQL access.
posted by mathowie (staff) at 8:19 AM on February 11, 2011 [1 favorite]


Our top concern with any feature is how it will affect site culture.

You guys blow me away with how damn awesome you all are.
posted by a snickering nuthatch at 9:07 AM on February 11, 2011 [6 favorites]


Well, let's see what we get:
var client = new XMLHttpRequest();
client.onreadystatechange = function() {
// in case of network errors this might not give reliable results
if(this.readyState == 4)
return (this.status);
}
client.open("HEAD", "http://metatalk.metafilter.com", false);
client.send();
console.log(client.status);
console.log (client.getAllResponseHeaders());
200
Date: Fri, 11 Feb 2011 17:11:13 GMT
Content-Encoding: gzip
Connection: Keep-Alive
Server: Apache
Vary: Accept-Encoding,User-Agent
Content-Type: text/html; charset=UTF-8
Keep-Alive: timeout=3
Run this several times and the status will always be 200. I don't know if that's because Chrome is doing some clever caching and reinterpreting the 304 as a 200 (unlikely, but firefox did this at one point) or if it's because Last-Modified is blank.
posted by boo_radley at 9:14 AM on February 11, 2011


No, you won't ever get a 304 from pages here. I'd use the RSS feed for something like this.
posted by pb (staff) at 9:18 AM on February 11, 2011


And just to confirm the hypothesis for the home viewers -- that's because the page is built dynamically each and every time, right?
posted by boo_radley at 9:31 AM on February 11, 2011


Yes, the page is built from scratch each time. There's some caching at various points, but entire pages aren't cached. Members have pieces of the page that are unique to that user including MeFi mail counts, favorites, flags, and more.
posted by pb (staff) at 9:41 AM on February 11, 2011


.-=,--=★ The more you know!
posted by boo_radley at 9:50 AM on February 11, 2011 [5 favorites]


Couldn't you use websockets?
posted by wayland at 10:32 AM on February 11, 2011


> sans grar

ungh, sockpuppet want
posted by Ambrosia Voyeur at 10:53 AM on February 11, 2011 [3 favorites]


ungh, sockpuppet want

ungh, sockpuppet want
posted by Rock Steady at 10:54 AM on February 11, 2011


times new grarman.
schmoopvetica.
Mathoma.
posted by boo_radley at 11:03 AM on February 11, 2011


How exactly do you propose it would be done then? Your ajax example is totally wrong and irrelevant because it assumes that the front page is a static document which it is not; it is a dynamic page. You will never, ever get a 304. This whole site is dynamic.

THANK YOU. I was reticent to ask as I'm not all that knowledgeable and just assumed there was some next-level-might-as-well-be-magic solution I was unaware of.
posted by juv3nal at 11:06 AM on February 11, 2011


juv3nal: "THANK YOU. I was reticent to ask as I'm not all that knowledgeable and just assumed there was some next-level-might-as-well-be-magic solution I was unaware of"

Look, it's not really next-level stuff if it's engineered to work that way:
Say you have a content page that feeds from a database. Like MF, it's dynamic; has all of its stuff in a database, each page is lovingly handmade. But we also have a webservice that checks last time the core content was update based on user prefs.

One auxilliary webservice that serves as polling isn't crazy-go-nuts overhead, right? No, of course not.

This isn't a suggestion that pb rush out to do these things, obviously. Realize, though, that it's possible and it's not magic. It does require planning which does seem to be next-level-magic for a lot of people (bitter about my job commentary).
posted by boo_radley at 11:22 AM on February 11, 2011


My experience has been that any request for a new feature, however laudable in principle, is always greeted with derision.

I don't think that's true. There've been a lot of minor feature/bugfix/enhancement requests lately; very little derision, very little drama.

The ones that don't go well are (a) ground already well-covered: threaded comments, downvoting, the edit window; and (b) requests that presume simplicity and priority, rather than letting mathowie and pb do their job of estimating and prioritizing their work.
posted by We had a deal, Kyle at 11:27 AM on February 11, 2011


For some reason Ajaxy stuff really slows down my computer and is basically what drove me away from Twitter. So far I'm not having a problem with the comment thing (beyond finding it really annoying), but I don't leave FPP pages open very often so I've only seen it a few times. I am very adverse to having more scripting built into each page, being so clean and small is one of the things that makes metafilter nice to use even on my old computer. Bells and whistles are all very nice for those with up to date hardware, but not everyone has that. At the very least please test changes like this on an underpowered piece of shit rather than assume everyone else gets to use awesome dev boxes, even better would be giving us an option to turn it off (even better better would be making it an option to turn it on).
posted by shelleycat at 11:30 AM on February 11, 2011


Thanks for all the thoughtful comments and I apologize if I came off as demanding.

BTW, it seems to me that the update thing hasn't been implemented for MetaTalk. If you don't dig my big pony how about this little Shetland instead? (Forgive me if this has already been discussed elsewhere.)
posted by twoleftfeet at 11:40 AM on February 11, 2011 [1 favorite]


We're stuck a little between wanting to increase functionality and wanting to have as many users as possible access the site and make use of the features. Things like Live Preview can be a bit of a slower-downer, but we really don't see this as something that will give even older machines a real CPU hit. Please let us know if you find otherwise. As it is since we're designing for mobile devices as well as regular old boxes, we usually take the CPU hit into account. I'm with you, loading a page on Twitter or Flickr now gives me so much bellwhistlearglebargle that I've started turning parts of it off via Greasemonkey. We'd like that to not be the case here, but this widget doesn't seem to us to be something that is likely to tip the scales.
posted by jessamyn (staff) at 11:40 AM on February 11, 2011


BTW, it seems to me that the update thing hasn't been implemented for MetaTalk.

We'll be rolling it out to other subsites soon; we've been running it only on mefi to start to let it gel and make sure we've got the kinks worked out in one place prior to generalizing it.
posted by cortex (staff) at 11:51 AM on February 11, 2011 [1 favorite]


OK, thanks.

A Greasemonkey script that would run on metafilter.com but check for updates from the RSS feed and change the document title for metafilter.com would be cool. Anybody have time to do this?
posted by twoleftfeet at 12:02 PM on February 11, 2011


Say you have a content page that feeds from a database. Like MF, it's dynamic; has all of its stuff in a database, each page is lovingly handmade. But we also have a webservice that checks last time the core content was update based on user prefs.

One auxilliary webservice that serves as polling isn't crazy-go-nuts overhead, right? No, of course not.


Right. I understand that although going to the db has the stigma of being a performance hit, in this particular instance, it isn't anything significant. But if no page ever returns a 304, doesn't your webservice have to go to the db?
posted by juv3nal at 12:10 PM on February 11, 2011


Yes, the page is built from scratch each time. There's some caching at various points, but entire pages aren't cached. Members have pieces of the page that are unique to that user including MeFi mail counts, favorites, flags, and more.

This sort of answers a question I have and sort of doesn't. Would selective caching, then, be why when I read a sidebar link on my work machine it correctly registers as read but when I read a sidebar link on my home machine, the link won't show up as read on the work machine (and vice versa)?

God, I'm sorry, that's a ridiculously confusing way to put it.
posted by librarylis at 12:34 PM on February 11, 2011


That's a browser cache thing, librarylis. The "I have visited this link" knowledge exists at a browser level, so two different machines will have to different histories of visited links. Has nothing to do with anything being cached on the server side.
posted by cortex (staff) at 12:38 PM on February 11, 2011


juv3nal: "But if no page ever returns a 304, doesn't your webservice have to go to the db?"

Yeah, that's all our web service does. Its backing view in SQL looks pretty close to SELECT MAX(field) FROM TABLE. Table has approximately 310000 rows in it, multiple relations, triggers, etc. Tracing shows that the IO cost is ~0.7 and CPU cost is ~0.009. Roundtrip on the webservice locally is ~20ms. So even considering the whole life of the request, the cost is negligible. Our server's a single MS SQL in some middling configuration -- maybe that colors things? I dunno.
posted by boo_radley at 12:38 PM on February 11, 2011


That's a browser cache thing

....that more or less makes sense. Thank you! It's been bugging me for ages.
posted by librarylis at 1:23 PM on February 11, 2011


Wouldn't this idea make for a strange UI experience since the page has new info at the top rather than the bottom?
posted by reductiondesign at 11:49 PM on February 11, 2011 [1 favorite]


That's an awesome pony, thanks!
posted by lizbunny at 3:43 PM on February 14, 2011


« Older Has the average number of posts increased?   |   What a revoltin' development this is Newer »

You are not logged in, either login or create an account to post comments