Who the hell invented the term Threadsuck anyway? The guy who invented the Perl thing for TT threads way back when? Or was it a commonly-used term?

The music question belongs in Bureaucracy (where it looks like a few folks have already expressed an opinion...).

Hi. My name is Liese, and I'll be agreeing with all your minority viewpoints for this evening.

I would not want threadsuck to mark as read. The ability to opt for this is acceptable. I would suck and archive to disk, carry the disk with me for further perusal whilst traveling offnet, and then expect to continue reading normally, until I left. However, this is my personal usage, and I will, of course, be happy with whatever consensus is.

I agree with Rob that the term threadsuck does not need to be part of our user interface. Intuitive is good. It took some effort to work out both threadsuck and ENUF as a newcomer to TT.

I have another threadsuck issue, but I'll segregate it.

Okay. Is there a difference in resource consumption between sucking the thread myself and downloading someone else's previously sucked thread?

In prior usage, we didn't own the board, and therefore didn't have the ability to add a threadsuck viewing/saving option. Threadsuck was an external program that we applied to an existing format. Doing it myself would take almost as long as it would to load all the pages individually, but it allowed me to easily view and search offline. (Thus, leather pants taxonomy.) However, downloading DX's previously sucked and zipped archives took much less time, and allowed me to continue to get usability even when my connection speed took a desert dive.

Would it be beneficial to us to add some sort of autothreadsuck and archive process to when we close threads, allowing for everyone to download the one file, as opposed to doing it ourselves every time?

The other usage is incomplete threads, which would still need to be individualized.

Enough for now.

Would it be beneficial to us to add some sort of autothreadsuck and archive process to when we close threads, allowing for everyone to download the one file, as opposed to doing it ourselves every time?

That's what I've been assuming. My expectation is that once the threadsuck utility is up, DX (or someone else) will suck all the closed threads and put them in the archives. ita will then delete those threads (either from the database or else just from the thread listings). Maybe we'd hold off on deleting recently closed threads, but after some agreed upon period of time (three months?) they'd be removed.

I was expecting the threadsuck utility to be used regularly on active threads, for users who want to catch up by reading offline.

Before we decide to delete, we need to decide what happens to links to threads that are deleted (really, I'd like to take the records out of the database). And also to be aware that they'll be unsearchable if we do so.

Good points.

we need to decide what happens to links to threads that are deleted

You know what would be cool? If a link points to a thread id that's been archived, a screen could appear that linked to the archived and zipped thread. There'd be an explanatory message, of course.

That would require putting some intelligence behind the location of the zipped threads -- for immediate use, we could just redirect to the archives page with all of them? It's kinda rude, but it's my first reflex.

But, if the discussion goes on long enough, an algorithm will create itself.

That would require putting some intelligence behind the location of the zipped threads

I was thinking of a table that could be easily updated by an admin, but a simple redirect is certainly fine for the short term.

I suppose "threadsuck" might look to the uninitiated like "threadspew" would look to me. I don't remember having that reaction, though.