Re^2: Limit of 300 in "older entries"?

[etj]

I didn't know there was a vote bonus. I said I wanted to constructively use them, and upvoting good nodes, even older ones, is something I feel is constructive (and yes, I do sparingly downvote too).

What is the reason for this arbitrary limit of 300?

[jdporter]

Cool. Thanks!

What is the reason for this arbitrary limit of 300?

I have no idea. For who can read the mind of vroom?

[LanX]

Not sure if was vroom, because the first patch is from demerphq and seems to have used a Everything engine page as a base.

But I found a later discussion justifying the 300...

tye: Blowing out the memory consumption of an Apache child is something that has been proven to have profound impact on the performance of the whole site and something that won't be undone for quite a long time

I think my guess wasn't too far fetched.

[jdporter]

But I found a later discussion justifying the 300...

tye: Blowing out the memory consumption . . .

Ha! In response to a patch I submitted to remove the restriction (except on the initial search).

Not sure if was vroom, because the first patch is from demerphq and seems to have used a Everything engine page as a base.

The current htmlcode, newlistapproved, was implemented on Everything devel on 2000-02-10, and imported to PerlMonks on 2000-03-15. It has author credits of both vroom and nate. Maybe nate did the development and vroom imported it here. That would be a common scenario. Who knows?
Earlier versions of the code (listapproved, etc.) did not have the limit.

Perhaps interestingly, Everything2 codebase does not have "listapproved"; no htmlcode in the vicinity of 2000-02/03 seems to have anything to do with listing writeups in sections. Maybe that's not surprising; E2 doesn't have the concept of sections, nor of approval.
E2's htmlcode nodes jump from 298 to 166222, all within the month of 1999-11 (while newlistapproved is node id 4692). This implies that:

1. listapproved (and newlistapproved) were originally implemented much earlier than 2000-02; and
2. e2 deleted (or never imported) a substantial swath of code nodes which live on at pm.

[etj]

Is this not an argument for implementing pagination like I've seen in various GraphQL implementations (among other things), where there is simply something like next=NODE_ID, and then it's selecting LIMIT 15 with a publication date earlier than that NODE_ID, ORDER BY publication_date DESC? Hard to see that having any memory impact.