PQ's and attachments

[+McCutchan Cache Clan]

For quite a while i've had a PQ running once a week that gave me the results for my finds in the past few weeks.

 

It would arrive in my email, with a winzip file attached containing the PQ.

 

Anyway now the email arrives, but no attachment, telling me it's available for for download. It's not problem logging back in to GC and going to the right place to download it, but it's just so much simpler to click on the attachment that used to be in the email.

 

So anyone got any idea on what's gone wrong and how to fix it?

[+Lil Devil]

If the file contains less than 500 caches, it will be sent as an attachment.

 

If there is more than 500 caches, it has to be downloaded.

 

If you absolutely want an attachment, just set the maximum caches to 500.

[+StarBrand]

By the way...

 

This sounds like a PQ that you setup - if you want all your finds - use the special "my fins" pocket query by clicking the "add to queue" button at the bottom of the PQ list.

 

Otherwise you are restricted to 1000 caches and no archived caches. The special PQ contains even archived caches.

[+GeePa]

if you want all your finds - use the special "my fins" pocket query by clicking the "add to queue" button at the bottom of the PQ list.

However, note that nowadays, regardless of how many finds you have, the My Finds pocket query always has to be downloaded from the site and does not ever come as an email attachment.

[+Gitchee-Gummee]

PQ v My Finds are not the same. Which is the discussion about?

[+jmoores]

It's not a big deal, as was said earlier in this thread, to go to GC and download the query, but I don't understand the logic for dividing between <500 and >500. If the PQ is mailed as an attachment or downloaded, I don't see how it would make a difference to CG. The query gets extracted either way, it has to be stored either way, and the only (transitory) resource usage is in the server(s) that actually sends out the email.

 

I know that there are some people who are still using a low speed/dial up connection but downloading vs email doesn't seem to matter because either way they would have to used the same bandwidth getting the PQ file.

 

Unless I'm missing something here, it might be more "user friendly" to add a switch to the PQ definition page to email or to download (like there is a switch to zip the file or not).

 

Thoughts anyone?

[+dfx]

It's not a big deal, as was said earlier in this thread, to go to GC and download the query, but I don't understand the logic for dividing between <500 and >500. If the PQ is mailed as an attachment or downloaded, I don't see how it would make a difference to CG. The query gets extracted either way, it has to be stored either way, and the only (transitory) resource usage is in the server(s) that actually sends out the email.

 

I know that there are some people who are still using a low speed/dial up connection but downloading vs email doesn't seem to matter because either way they would have to used the same bandwidth getting the PQ file.

Actually email delivery takes quite a bit of a larger hit on a server than simply storing the files and then handing them out over HTTP when they're requested. The issue isn't so much bandwidth (even though email delivery requires 33% more bandwidth due to the necessary encoding) but mostly disk I/O. You don't simply send out emails and then forget about them, they need to be queued, scheduled, requeued in case the destination server is down or has other problems, you need to handle bounces, generate error emails, etc etc etc. There's a lot of overhead involved. Email systems can be a pain to maintain and run.

 

Unless I'm missing something here, it might be more "user friendly" to add a switch to the PQ definition page to email or to download (like there is a switch to zip the file or not).

While I would like that, I can totally understand that they'd like to get rid of the email deliveries (as explained above). What I don't understand is not providing an alternative to them.

Edited March 17, 2011 by dfx

[Pup Patrol]

- use the special "my fins" pocket query

 

 

Hmmm, sounds fishy to me.

 

 

 

sorry, sorry, sorry...but I just couldn't resist.

 

I'll go sit in the corner now.

[+jmoores]

It's not a big deal, as was said earlier in this thread, to go to GC and download the query, but I don't understand the logic for dividing between <500 and >500. If the PQ is mailed as an attachment or downloaded, I don't see how it would make a difference to CG. The query gets extracted either way, it has to be stored either way, and the only (transitory) resource usage is in the server(s) that actually sends out the email.

 

I know that there are some people who are still using a low speed/dial up connection but downloading vs email doesn't seem to matter because either way they would have to used the same bandwidth getting the PQ file.

Actually email delivery takes quite a bit of a larger hit on a server than simply storing the files and then handing them out over HTTP when they're requested. The issue isn't so much bandwidth (even though email delivery requires 33% more bandwidth due to the necessary encoding) but mostly disk I/O. You don't simply send out emails and then forget about them, they need to be queued, scheduled, requeued in case the destination server is down or has other problems, you need to handle bounces, generate error emails, etc etc etc. There's a lot of overhead involved. Email systems can be a pain to maintain and run.

 

Unless I'm missing something here, it might be more "user friendly" to add a switch to the PQ definition page to email or to download (like there is a switch to zip the file or not).

While I would like that, I can totally understand that they'd like to get rid of the email deliveries (as explained above). What I don't understand is not providing an alternative to them.

 

Thanks for the reply... I'm not sure that I entirely understand... If GC already maintains mail servers, then offering an email option over 500 caches probably wouldn't increase the need to expand the number of servers (perhaps some more disk space to hold the larger attachments but disk is probably the cheapest part of any server), and especially if GC would make zipping all PQ >500 attachments manditory. I do agree that mail servers are a pain to maintain (having maintained email, fax, FTP servers in my 30+ year career in data processing)... but just adding the capability to email the over 500 PROBABLY wouldn't be significant increase in the number of emails being sent? Obvious that probably is an assumption on my part... based upon how I typically use PQs.

 

I'm not sure that I can think of an alternative to downloading or emailing? FTP would be about the same as downloading and probably far less user friendly. Is there another option?

[+dfx]

I do agree that mail servers are a pain to maintain (having maintained email, fax, FTP servers in my 30+ year career in data processing)... but just adding the capability to email the over 500 PROBABLY wouldn't be significant increase in the number of emails being sent? Obvious that probably is an assumption on my part... based upon how I typically use PQs.

Probably right, but I think the plan behind the change was a different one: the more people switch to >500 PQs, the less email they'll have to deliver. It's not about not increasing load on the mail servers, it's about easening it. Webservers are their main thing already, so it makes sense wanting to move the load there.

 

I'm not sure that I can think of an alternative to downloading or emailing? FTP would be about the same as downloading and probably far less user friendly. Is there another option?

It's been discussed extensively back in the day when >500 PQs were introduced. Lots of ideas were proposed, none were implemented. HTTP download would be fine by me if I could do that without having to be logged into the website. Some kind of single-use authentication keys (part of the download link) would be sufficient. Notification about ready-to-download PQs could remain through email, or for example through an RSS feed (even less email traffic this way). But it looks like Groundspeak isn't interested in providing any functionality like that.

Edited March 17, 2011 by dfx