Actually, no, Jon. I wasn't thinking the page would just dump a file on the user. I was envisioning an intermediate page where one can pick the range of posts, the behaviour (mark read?), and perhaps even have the file zipped before it's handed off.

Usability Queen! Do I get a tiara?

I think the threadsuck control panel is a good idea, if a little confusing in the current iteration, if we think people will use it. And I'm impressed, if surprised, that there are no vampire jokes anywhere on it: that takes restraint.

With Jon's proposal, you'd have

Natter 4,345: The Cheese Continues
Subscribe | Download entire thread | Download unread posts.

My feeling is that unless we know a lot of people want to use the threadsuck option, it's a lot of choice to be surfacing at the top level. ita's intermediate page suggestion, especially if you can set default options and just click OK when you get to that page, might be a better idea if most of our users are reading online.

I was envisioning an intermediate page

OK, I get it. Let me work out a revised intermediate page design. Maybe something that allows an easy download of the referring thread at the top of the page, with more options for other threads below that?

that takes restraint.

It was tough, let me tell you!

I agree that we should have an intermediate page, because people will click on things just to see what happens (it's their right as users) and even the word "entire" won't be enough to put them off.

What might be useful is teaching people how to get the file to download directly to disk rather than appear in their browser first, then get saved.

If I option-click on a link in IE on Mac, that's "download rather than display this link".

What might be useful is teaching people how to get the file to download directly to disk rather than appear in their browser first, then get saved.

Is there a way we set up the server so that happens by default?

Also, would it be cool to run the result through gzip before downloading? It would save bandwidth.

Well if we did the second, then the first would happen anyway, wouldn't it?

But I don't know if you can tweak the headers to make it download rather than display, plus people might prefer it to display rather than download, so you'd have to add yet another choice to the form.

Well if we did the second, then the first would happen anyway, wouldn't it?

In my experience, not always. On rare occasions, I've been shown a .gz file as web content. There's something on the server that makes the save to disk thing happen, I think. I suspect MIME is involved.

It's a MIME/browser combination. Opera tends to display more things than IE.

I suspect MIME is involved.

Oh yeah, I'm sure that's what's going on, but I don't know how difficult it is to set the headers for outgoing files.

I know for instance that when you're doing this in Perl, you get to set the MIME type specifically, like you write:

Content-type: text/html

in your script. So if you wanted to change that to:

Content-type: application/zip

for a zip file, you can do it easily.

But if it's not a zip file, it really is a text/html file, but we want to try and trick the browser into handling it differently? Hmmm.

Also that kind of thing, making the headers explicit, is exactly the reason why people use PHP instead of Perl, so that you don't have to do that.

I might research this a little.

OK you can set whatever damn headers you want with the PHP header() function: [link] but that doesn't solve the force-download problem, does it?