Re: Re: Renovating Best Nodes

[demerphq]

Yep. I was planning to wait on that one until the number of nodes could be user controlled.

Sorry about All-Time Best, but hopefully it will be for the best in the end. :-)

[tye]

I'm pretty sure you'll not get user preferences in the nodelets for quite a while (if ever). Nodelets are rendered on every page load and so are best when they can be cached. And cached nodelets can't be user-specific.

Your caching for best/worst nodes is quite nice but it still reads quite a few records out of the database. Doing that 4 times for every page load would probably end up with more DB load than we had before your work.

[demerphq]

I'm pretty sure you'll not get user preferences in the nodelets for quite a while (if ever). Nodelets are rendered on every page load and so are best when they can be cached. And cached nodelets can't be user-specific.

Yep. When i wrote that reply I hadn't realized the implications of the node caching on what I was saying. In fact I _keep_ forgetting them.

Your caching for best/worst nodes is quite nice but it still reads quite a few records out of the database. Doing that 4 times for every page load would probably end up with more DB load than we had before your work.

I agree totally. Would it be too much (in terms of policy etc) to make small versions of the various nodelets? With say 5 lines in each, and a link to their respective full page version?

[halley]

I see two issues: (1) user arguments to control a widget is not well-established here, so you're "waiting" for a lot to be implemented; and (2) wouldn't user-controlled best counts be harder on the server? At minimum, you'd have to calculate the maximum "selected" nodes for a given refresh time, then save multiple versions of nodelet content.