More control over Newest Nodes list

[Wassercrats]

This node falls below the community's threshold of quality. You may see it by logging in.

[phydeauxarff]

I am pretty sure this would require a fairly significant re-write.

I believe the flag is currently built off the lastviewednewestnodes var and the logic is display stuff if newer than that.

what you would propose would require the ability to mark a specific node as viewed, not a list of nodes that post-date lastviewednewestnodes. This would probably be implementable via another table but I would bet that the database overhead of checking this for every node and every user would make it unworkable

[hv]

For what it's worth, I recently implemented something similar for my work application, to keep a one-bit-per-node vector of "messages seen". In my case, those flags are updated whenever the server attempts to deliver the node to the user, and this hasn't caused a significant extra load (with the busiest site serving a choice of 27k nodes to 24k users, and sharing the web and database servers with 21 other live sites).

We use the information to specify the class of the node title as 'seen' or 'unseen', and it has made it far easier to find new information in a useful fashion.

For PM, the size of the vector would be larger, but updating it only as a result of an explicit request would balance that. I suspect the main difficulty would be the UI design: individually selecting a subset of 100 or more checkboxes on Newest Nodes would be unpleasant.

Hugo

[naChoZ]

One possible alternative would be to use the Personal Nodelet (or duplicate with a different name, perhaps "Checked Nodes"). A check box could be placed next to items in the Newest Nodes list and the Super Search results, intentionally omitting a Select All button. Those nodes could then be bulk inserted into the Personal Nodelet.

[demerphq]

phydeauxarff has the correct explanation as to why this request will never go anywhere. This might work for a low load site but for one like PM forget it.

[Solo]

A glance at the html source for Newest Nodes shows a 'pageloadtime' variable that holds a value in seconds since the epoch. One could probably use that to gain some finer grained control over the list. For instance, you might be able to bot updating the last checked flag, every 30 mins, with a pageloadtime that's 1 hour ago. It's actually interesting enough that I might try it later today.

[jdporter]

Ya gotta remember that the web interface is just one possible implementation of a PerlMonks client. There are several other clients out there, and frankly it's just not that hard to write a new one. I myself just wrote one that displays a continuously* updated listed of new nodes. Old ones scroll off the top (with a scroll-back buffer, of course). With such a client, your concern becomes moot.

* More like continually. It polls at proper intervals, and doesn't ask for more than it needs.

[naChoZ]

There was also a bit of related discussion in Getting Complete Listing Of [Super Search] Results.