Jump to content

Pq Suggestion: Position In Queue


robertlipe
Followers 2

Recommended Posts

Therevision to http://www.geocaching.com/pocket/ that allowed us to store and schedule 20 PQs relatively independently was probably my favorite site change in recent memory. It's very nifty. Here's a request to make it even more nifty Sometimes (esp. right before travelling) it'd be handy like to know approximately when the PQ will fire.

 

If a PQ is scheduled to run and hasn't run yet on any given day, it would be most helpful if you could see approximately where in the "TODO" list you are. If you are #2 of 139 and that last number has done nothing but grow for the last six hours, you can figure something is stuck. If you're #138 of #139 and and hour passes and you're now #135 of 140, you can guess sitting and waiting for it isn't a good plan and you should probably move on.

 

I understand that PQs can be cancelled and new ones created that'll go above you in the run list so perhaps absolute numbers aren't totally appropriate. I wouldn't want to contribute to hyper-PQ-ification ("It's been three minutes. Where's my PQ. Waaaa!") but I think a relative position showing a more direct status would be helpful.

 

Even if the idea is dismissed, thanx for listening.

Link to comment

It's an interesting request. The query to get the current count (and find your place in that queue) is kind of messy, but doable.

 

I do have an alternative. Because they run in descending order by date last generated (so a PQ that ran yesterday will run today but after an older PQ is run), I could just allow people to "bump" their PQs to the front of the queue. The reasoning behind the current ordering is that standard daily-run queries may or may not be used, but an active member who wants their PQ NOW and doesn't want to wait can bump it to the front of the queue.

 

Behind the scenes it is really just doing a copy/paste of your query to another PQ number thus making it a new query and running it again. What do you think? Or was I just rambling...

Link to comment

That's a more direct solution. Instead of answering "are we there yet", just bump it to the front of the line above the bulk tasks. That'd be consistent with OS schedulers processes interacting with a human usually get scheduled before the bulk tasks that are just along for the ride. It doesn't help with the intermittent "is it dead" questions, but those are supposed to be rare.

 

Perhaps even easier than a copy would be to just reserve one digit in the key for a "bump" that defaults to one and gets zeroed on a bump, thus forcing it to the front of the line.

 

PQ200505041123456 - unbumped PQ '123456' for today. Tweak the digit between date and job number and it'll all resort like I think you want becuase you've just fast forwarded it by a very significant digit.

 

(This is probably an inappropriate amount of detail; I'm just thinking out loud.)

 

I would find such a change helpful. Thanx for considering it.

Link to comment
It's an interesting request. The query to get the current count (and find your place in that queue) is kind of messy, but doable.

 

I do have an alternative. Because they run in descending order by date last generated (so a PQ that ran yesterday will run today but after an older PQ is run), I could just allow people to "bump" their PQs to the front of the queue. The reasoning behind the current ordering is that standard daily-run queries may or may not be used, but an active member who wants their PQ NOW and doesn't want to wait can bump it to the front of the queue.

 

Behind the scenes it is really just doing a copy/paste of your query to another PQ number thus making it a new query and running it again. What do you think? Or was I just rambling...

Perhaps if the user checks "Only run this query once (then remove it)" you could put these at the head of the queue.

 

I have a request to be able to save more than 20 PQs. I get all the caches in my area (cache dense So. Calif.) in three groups of queries that run on different days of the week. There are currently 11 queries in all but at the rate of cache growth around here that number is going to go up and I'm afraid that soon all 20 PQs will get used up.

Link to comment
Perhaps if the user checks "Only run this query once (then remove it)" you could put these at the head of the queue.

New queries are already at the front of the queue, so this should happen already.

 

If a bumped query isn't coming through within, say, 30 minutes, there is some issue with the PQ server. New queries are actually performed by their own separate process so they stay at the front of the queue.

 

I have a request to be able to save more than 20 PQs.

 

I have seen this request before. I'll look into it.

Link to comment

[ /me continues to mumble aloud from the voices inside my head. ]

 

Actually, instead of zero or one, it could just be a numeric priority from zero to nine defaulting to five or something. Then you could have bulky "when I have nothing better to do" queries scheduled at an even lower priority than the regular ones. Might be handy for "foundy by" PQs or bulk data delivery to partners or such.

Link to comment

I have a request to be able to save more than 20 PQs.

 

I have seen this request before. I'll look into it.

Any progress on this. I really need to store more than 20 PQs, I don't mind only having the ability to run only 5 per day. The overhead in storing more than 20 is minimal, and there is no change on the bandwith used in downloading

Link to comment
I guess the problem comes in what happens when EVERYONE starts pushing the PQs to the front of the line.

I doubt that would happen, because many of the PQs are probably scheduled maintenance runs that folks have scheduled to run routinely, whether they need them or not. And I would bet that many PQs are run for folks that have stopped geocaching, either temporarily or permanently.

 

But even if it does not completely solve the problem, it does seem to solve the type of problem that the most avid cachers consider a "crisis" (since it actually keeps them from geocaching). I would love to see this.

Link to comment

I have a request to be able to save more than 20 PQs.

 

I have seen this request before. I'll look into it.

Any progress on this. I really need to store more than 20 PQs, I don't mind only having the ability to run only 5 per day. The overhead in storing more than 20 is minimal, and there is no change on the bandwith used in downloading

 

that is what I suggested several weeks ago -

 

that maybe part of the problem with not getting our PQ's might have something do do with so many people pushing to the front of the line with 'instantaneous' PQ's.

 

cc\

Link to comment
I guess the problem comes in what happens when EVERYONE starts pushing the PQs to the front of the line.

I doubt that would happen, because many of the PQs are probably scheduled maintenance runs that folks have scheduled to run routinely, whether they need them or not. And I would bet that many PQs are run for folks that have stopped geocaching, either temporarily or permanently.

 

But even if it does not completely solve the problem, it does seem to solve the type of problem that the most avid cachers consider a "crisis" (since it actually keeps them from geocaching). I would love to see this.

 

There was some discussion a while back about detecting 'inactive' cachers and stopping their PQ's to regain the bandwidth, until they came back in and made some activity to turn them back on. I agreed with that. Seems there could be many ways of doing this - several were suggested.

 

What happened to those ideas?

 

cc\

Edited by CompuCash
Link to comment
What about just allowing each premium member to designate 1 or 2 PQ's as " Priority" PQ's. Most people would use their " local" or Home" PQ as a priority one and possibly one for an area they are travveling in.

No. Everyone and their brother would do that. Most people don't cache every single day, yet they would ask for a "priority" PQ to be delivered everyday. Kinda like is happening now. The priority thing needs to be human-triggered every time, when they know they are going caching.

Link to comment
There was some discussion a while back about detecting 'inactive' cachers and stopping their PQ's to regain the bandwidth, until they came back in and made some activity to turn them back on. I agreed with that. Seems there could be many ways of doing this - several were suggested.

 

What happened to those ideas?

I strongly disagree with this suggestion. The so-called inactive cachers have paid for their memberships and have just as much right to receive their PQs as anyone else.

Link to comment
Guest
This topic is now closed to further replies.
Followers 2
×
×
  • Create New...