What about the pending request for one to be able to mark posts unread?

That would help matters, though it would still be problematic after the fact. Say a person's read up to post 7386 and they threadsuck when it's reached 7621. After they've done so they realise that the facility has now marked all their posts as read. How do they work out where they were up to, in order to mark the right posts as unread?

The read/unread thing is primarily a placemarker. I don't think it's reasonable to move that placemarker for anything other than posts actually being read.

How do they work out where they were up to, in order to mark the right posts as unread?

Using the back button.

Honestly, people seem to skip ahead and go back quite a bit, and it's not hard. Not taxing on the server either.

Using the back button.

That kind of presupposes they're still have the same session loaded up. There's no reason to assume that the person is planning to go on to read posts at the same time as their threadsucking activities.

I'm aware we're talking about a smaller subset of likely usage here. But I think that's the case either way. I would expect most threadsucking to be done on threads that have already been read to the end. So as I see it, the issue is simply one of flexibility. The only point on which I see the two options differing in any significant way is the ease with which a person can replicate the option they personally favour.

Honestly, people seem to skip ahead and go back quite a bit, and it's not hard. Not taxing on the server either.

How much do you actually expect to save off the bandwidth from having the threadsucker mark posts as read? Do you really expect it to make any sort of noticeable dent in usage? I'm having trouble imagining it wiping even a percentage point off current usage.

Honestly, if 95% of people want it to not mark read, then I'm good with it. If 95% of people want it marked read, I'm good with it.

That's my major POV. I don't think a solution that puts more load on the server or uses more bandwidth should be architected for people who don't exist. Once the demand is identified, then sure. But why start out that way if not many people care?

That's my major POV. I don't think a solution that puts more load on the server or uses more bandwidth should be architected for people who don't exist.

That's kind of the point of my second question. I don't think it will ever make a material difference to the load on the server or bandwidth. I think the issues are minor on both sides. The situations I think we should accommodate will not occur very often, and the gains you're talking about are going to be marginal at best.

Certainly at least one such person exists, namely myself. I don't see threadsucking as being a substitute for reading the posts onsite; and, again, if it is, then why do we have the current site design instead of a design replicating the threadsuck look? If we believe the current site design adds value to the Phoenix board (and I believe it does), then why would we not expect people to want to use it in preference to a threadsucked file?

I have thread-sucked and read large threads off-line -- I can see that some people might want to download a complete thread, like to a Palm Pilot, to read elsewhere. But generally, I'd do it by setting my page load to 10100 posts and hitting "Recent" if I was going to do it.

If the threadsuck leaves in all the extraneous admin links and stuff

Take a look at the sample sucked thread I created, DX. All that stuff has been removed.

RE: The Great Marked as Read Debate. The way I've got it coded, there's a & variable you can stick in the threadsucked thread URL that controls whether the last-read-post variable is updated. All I'm looking for feedback on is what the *default* should be.

RE: The Great Marked as Read Debate. The way I've got it coded, there's a & variable you can stick in the threadsucked thread URL that controls whether the last-read-post variable is updated. All I'm looking for feedback on is what the *default* should be.

So the user can select their preferred option in any case? I'd go for mark as read then. If all it does is set a default, we may as well go with the majority vote.

Take a look at the sample sucked thread I created, DX. All that stuff has been removed.

Saw it, and it looks great.

So the user can select their preferred option in any case?

Sort of. My coding works thusly: There will be a link or links on the thread pages (like this one here), that say "Threadsuck all" and/or "Threadsuck new". Clicking on the link generates the threadsucked page. If you looked at the URL of the page in the address bar, you'd see (among other things) "&mark_read=yes" (or something similar). If you didn't want to update the last unread post, you would have to right-click, select "copy shortcut" (or your browser's equivalent), paste the shortcut into the address bar, and then manually change the &mark_read variable to "no". Not the easiest thing, but certainly doable.