Right. And on the rare occasion where a thread might be archived by someone who hasn't read it yet, wouldn't they ("they" probably being DX in this case) just archive it as "Admin," rather than using their own user id?

I've been archiving using my Lt. Charpe ID. If the threadsuck leaves in all the extraneous admin links and stuff, as a direct download of an entire Phoenix thread does, archiving while having admin privileges would really leave the thread looking kind of messy, all those delete and edit links on every post, etc.

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.