Jump to content

Notification Service (beta)


WildGooseChase

Recommended Posts

Jeremy,

 

Not being critical, just want to know the rational for not having an ALL CACHE TYPE selection on the pull down menu. I want to be able to be notified of any new caches around three distinct zip codes (three different geographic regions). As it is set up now I need to repeat the entry for cache notification 10 times (one each for each type of cache) for each zip code. I can only do one zip code, because of the 10 notification limit.

 

If you had a ALL CACHE TYPE selection on the pull down menu, I could simple create three different notifications for the three different zip codes, instead of 30 different notifications.

 

Again, not being critical, just trying to understand the thinking. Thanks for all the great work that is done out there.

Link to comment

Here's the other question I have about the new services as promised in the "Published" action thread:

 

What about an RSS feed for these notifications?

 

Regional organizations would love it, people's geocaching blogs would love it, and so on.

 

I would imagine you could do this easiest by setting up some sort of system standard notification set (the "Published" feed = all caches getting their "Published" action, the "will attend" feed = all "will attend" actions). Trim out some of the fat added to the fact that the e-mail is used to link to the "action". XML it and you're ready to go.

 

Ingenuitive users on the other end of the RSS could filter for the information they were particularly interested in (MDGPS could check the feed for MD only items to syndicate).

 

One nice part to this would be not flooding inboxes in areas that are going to have a ton of potential notifications.

Link to comment
And on a related note, do you think it would be useful to add a "Test notification" button?  This would help in working out any bugs in the filtering process.

 

Hmm... I need to hear more. How do you see this working?

The test button would simply have the server send a sample notification to the specified email address right away, instead of waiting days/weeks/months for a new cache to appear. This would let the user verify that it does indeed work and also make sure any filters, spam catchers or text messaging setups are working as well. The text of the sample could be as simple as "This is only a test. Had this been an actual notification, the email would contain actual cache listings and would be followed by the revving of engines and squealing of tires..." :laughing:

 

As I said, I think some people would find it useful to verify their email setup, but not everybody. I think that since this feature seems to target the FTF group, they would appreciate the peace of mind they'd get knowing that the system will run like clockwork the next time a cache is placed. I will be happy either way; it's nice just to see the new features develop. :(

Link to comment
What about an RSS feed for these notifications?

As part of the additional digest functionality (instead of instant) we have been considering RSS feeds as well. We are, however, doing our best to reduce the amount of traffic hitting the web site and RSS feeds on dynamic data can be a bit problematic when there are overaggressive RSS readers.

Link to comment

The test button would simply have the server send a sample notification to the specified email address right away, instead of waiting days/weeks/months for a new cache to appear.

Ah. Makes sense. Unfortunately the way that notifications currently work, the "test" wouldn't actually be a true test of your notification. It would just send you an email just like an email a user function.

 

Instead, as I add new log types you could add one that happens often (like "note" or "found it") to test it out. I just added archive/unarchive and we'll be adding other log types soon enough.

Link to comment
What about an RSS feed for these notifications?

As part of the additional digest functionality (instead of instant) we have been considering RSS feeds as well. We are, however, doing our best to reduce the amount of traffic hitting the web site and RSS feeds on dynamic data can be a bit problematic when there are overaggressive RSS readers.

Hmm, I'll think about this. I'd imagine there's a way to fake a 304 on only those readers that are grabbing at a frequency higher than you want to allow.

Link to comment

Hmm, I'll think about this. I'd imagine there's a way to fake a 304 on only those readers that are grabbing at a frequency higher than you want to allow.

If you can find an off the shelf tool to do that I'd give you a free annual membership.

Link to comment

Since the request was made prior in this thread I might as well post here that the bookmark notifications now have a link back to edit that bookmark list. It seems unless there are any weirdness that I will officially announce the notification service tomorrow.

Link to comment

Hmm, I'll think about this.  I'd imagine there's a way to fake a 304 on only those readers that are grabbing at a frequency higher than you want to allow.

If you can find an off the shelf tool to do that I'd give you a free annual membership.

Hmm. I may keep looking but here's what I've found so far:

 

Good overview of the approaches to take to reduce RSS bandwidth (gzip via your HTTP settings and conditional GET aka 304 pushing):

 

http://www.theappleblog.com/2005/05/03/rss...sing-bandwidth/

 

Most of these overviews link to this specific description of the issue (including dynamic content RSS provider info):

 

http://fishbowl.pastiche.org/2002/10/21/ht...for_rss_hackers

 

Someone saw that and wrote a PHP function to do the checking of headers or sending a 304 in the case that the reader isn't configured to handle conditional GETs (so all readers using your feed would need to be polite essentially):

 

http://simon.incutio.com/archive/2003/04/23/conditionalGet

 

No matter where I look, these same two sites (#2 and #3 above) are referenced as the state of the art on keeping bandwidth down even for dynamic content RSS feeds (along with gzipping via your HTTP server).

 

EDIT: Prolly not the "off the shelf" solution you are looking for, but I'll keep my eyes open.

Edited by ju66l3r
Link to comment
Since the request was made prior in this thread I might as well post here that the bookmark notifications now have a link back to edit that bookmark list.

Thanks, Jeremy. I've received my first bookmark e-mail with that link. That will also help me automatically route e-mails...once I figure out my ListIDs.

Link to comment

Has it been mentioned yet that the "Distance in Miles" entry is not being listened to? Just minutes ago I recieved an Insta-Notify emial for a cache that is listed as 12.9 miles away... but my subscription is set to 10. Forgive me if it has already been reported, but it seems kind of important not to mention. Other than that, the service is looking pretty good.

Link to comment

I'm receiving published logs for my area now. I also had 11 of my own caches approved. I received 22 emails. Is there anyway to put a check in so that you don't receive either the original approval listing or the new published listing for your own cache if the other is already being sent?

Link to comment
Has it been mentioned yet that the "Distance in Miles" entry is not being listened to? Just minutes ago I recieved an Insta-Notify emial for a cache that is listed as 12.9 miles away... but my subscription is set to 10. Forgive me if it has already been reported, but it seems kind of important not to mention. Other than that, the service is looking pretty good.

I'll second this to get Jeremy's attention. I have a notify (ID=81) with a 40 mile limit. I got a notify this morning for archiving a cache that is 55.6 miles away.

Link to comment

I tooo would like an "all cache types" , so as to avoid having to duplicate the process X times.

 

Alternatively, instead of a drop down menu, perhaps we could have boxes we could check or uncheck?

 

Another request - could other log types be added? For instance: "TP dropped" comes to mind. Or DNF.

 

Thanks!

Link to comment

 

Another request - could other log types be added? For instance: "TP dropped" comes to mind. Or DNF.

 

Thanks!

I wouldn't like TP dropped in my caches!

 

;)

You've never been in the woods and just had to go? TP in a cache could be useful. Just make sure you leave that type of log outside the cache.

Link to comment

Made two changes today:

 

1. Publish and Retract logs can now be deleted by the cache owner. This is to be consistent with other log types like enable/disable and archive/unarchive. The reviewer can designate a log undeletable however but during the normal publishing process you can remove the log.

 

2. There was an issue with editing notifications where it did not change the search area. If you made changes you the area of your search you will need to re-save it.

 

Distances should be more accurate now.

Link to comment
Has it been mentioned yet that the "Distance in Miles" entry is not being listened to?  Just minutes ago I recieved an Insta-Notify emial for a cache that is listed as 12.9 miles away... but my subscription is set to 10.  Forgive me if it has already been reported, but it seems kind of important not to mention.  Other than that, the service is looking pretty good.

I'll second this to get Jeremy's attention. I have a notify (ID=81) with a 40 mile limit. I got a notify this morning for archiving a cache that is 55.6 miles away.

Similar effects have been reported here in the German speaking forum. Seems like when you enter a max. distance in km (or even M) it gets reinterpreted/-calculated to miles...

 

BS/2

 

Edit: well, if that's so, then never mind...

Edited by BalkanSabranje
Link to comment

Disclaimer: this may have been mentioned before...

 

Jeremy,

 

I was just notified of a new cache that isn't approved yet. Of course no coordinates visible, but just the same I thought it was worth mentioning.

 

An Error Has Occured

Sorry, you cannot view this cache listing until it has been approved.

 

Here it the email -

This is an automated message from Geocaching

 

Location: Washington, United States

1.7mi NW (2.8km NW)

hydee published Kali's Queen Anne Kache (Traditional Cache) at 8/3/2005

 

Log Date: 8/3/2005

Published

 

Visit this log entry at the below address:

http://www.geocaching.com/seek/log.aspx?LU...6f-c918bb1c8a9d

 

Visit Traditional Cache

Kali's Queen Anne Kache

http://www.geocaching.com/seek/cache_detai...b2-456a450d01cc

 

Profile for hydee:

http://www.geocaching.com/profile/?guid=99...e7-ecb9e572b79f

 

Notification: NewSeattle

http://www.geocaching.com/notify/edit.aspx?ID=2775

Link to comment
It looks like that was just a test that hydee was doing. The cache was retracted (un-published) before you went to view the page.

My Bad,

I almost forgot we were on the Groundspeak Test and Production environment all the same time ;)

Indeed, I just was coming here for precisely the same cache notification. Curiously, there was no such retraction, disabled, etc. notice as there has been on other caches that get published and then withdrawn by approvers. Sure wish there was some way of telling the difference between a test notification and a real one - I just spent the afternoon diligently watching/repeatedly rechecking, expecting that it was just a brief timelag hiccup between Groundspeak and gc.com. Apparently that was a waste of time... :laughing:

Link to comment

Would it be possible to include the cache ID in the notification EMail? I am in the field all day, and IF there were a cache approved in the area I was working in, I can't use the link provided in the current EMail (antique WAP cellphone). If I had the ID, I could look up the cache and get the co-ordinates for that desperately coveted FTF... :wacko:

Link to comment
I just spent the afternoon diligently watching/repeatedly rechecking, expecting that it was just a brief timelag hiccup between Groundspeak and gc.com.  Apparently that was a waste of time...  :lol:

So, how many times did you recheck/refresh the link? Fess up! :lol:

 

Until the official announcement (there hasn't been an official announcement yet, right? Maybe I missed it though), I would treat all insta-notify messages as beta-testing and use at your own risk. :lol: I'm happy to test it out!

 

--Marky

Link to comment

This is great. Unlike Phoenix, I don't see a huge rash of new caches up here to race out and get, thus I've lost my proficiency as the FTF-hound. But some things relating to this were being discussed a Helena event I drove to this past weekend, and I bit my tongue about saying anything. Two of the cachers there came with me from Billings, so what they don't know...will work in my favor. :rolleyes:

Link to comment

I tried a search first, so if this has already been discussed, just markwell me!

 

I submitted my first new cache since the alert system has been in place and I noticed that I received 3 emails about it.

 

1) the standard note that the reviewer had published my cache

2) an email as the owner of the cache that a reviewer had posted a note (publish)

3) email notification of a new cache (in line with my notifier settings)

 

Is there any way to eliminate the last 2 emails based on my user id? I don't need to be notified that a new cache was just approved if it's mine and I don't need a notice of someone posting a log since I already received the auto-email that my cache submission was made active.

 

Not a huge issue in the grand scheme of the website, but would cut down multiple emails going out on your side and coming into my inbox.

 

Thanks!!

Link to comment

I think I hit most of the bugs in the most recent patch to the site. I also updated the notification application itself so it adds the name of the notification and a link to edit it.

 

For the UI I tweaked it a bit and added a toggle checkbox so you can disable or enable your notifications with a quick click. No bulk removals however.

 

The only thing I may have missed is when you exceed 10 queries. I'll have to check into that one again.

Sorry to bring back an old thread, but that's the only post I found that related to my question. :)

 

I've setup 20 notifications and when trying to get the 21st in, I get the following error (shouldn't it say something like "You have reached maximum notifications (20)"):

 

Server Error in '/' Application.

Input string was not in a correct format.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

 

Exception Details: System.FormatException: Input string was not in a correct format.

 

Source Error:

 

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

 

Stack Trace:

 

[FormatException: Input string was not in a correct format.]

Microsoft.VisualBasic.CompilerServices.DoubleType.Parse(String Value, NumberFormatInfo NumberFormat) +195

Microsoft.VisualBasic.CompilerServices.DoubleType.FromString(String Value, NumberFormatInfo NumberFormat) +82

 

[invalidCastException: Cast from string "). Remove one to create a new no" to type 'Double' is not valid.]

Microsoft.VisualBasic.CompilerServices.DoubleType.FromString(String Value, NumberFormatInfo NumberFormat) +171

Microsoft.VisualBasic.CompilerServices.DoubleType.FromString(String Value) +7

Geocaching.UI.LogNotificationControl.BuildControl() +335

Geocaching.UI.notify_edit.Page_UserLoggedIn(Object sender, EventArgs e) +1104

Geocaching.UI.WebformBase.IsLoggedIn() +1087

Geocaching.UI.notify_edit.Page_Load(Object sender, EventArgs e) +99

System.Web.UI.Control.OnLoad(EventArgs e) +67

System.Web.UI.Control.LoadRecursive() +35

System.Web.UI.Page.ProcessRequestMain() +772

 

Version Information: Microsoft .NET Framework Version:1.1.4322.2300; ASP.NET Version:1.1.4322.2300

Link to comment
What about an RSS feed for these notifications?

As part of the additional digest functionality (instead of instant) we have been considering RSS feeds as well. We are, however, doing our best to reduce the amount of traffic hitting the web site and RSS feeds on dynamic data can be a bit problematic when there are overaggressive RSS readers.

 

Consider this: You know exactly when an RSS feed should change. You could write the RSS files to the disk, and serve them statically, which is far less resource intensive on your web server, because you don't have to touch the ASP engine at all.

 

This is really just caching taken to the next logical step in web application server performance tuning.

1) cache queries.

2) cache pages.

3) write pages to disk and serve them statically

 

VC1.

Link to comment

This has been fixed and will show up in the next release (later today *fingers crossed* )

Thanks! :)

 

Hmpft.. this then confirms that we only have 20 notifications. :)

It is fixed! You can uncross you fingers! :)

 

Can't give you everything at once.. gotta dole it out so we can impress you every now and then :)

 

-Raine

Ok then.. here and idea that would reduce the number of notifications.. why not have a notification for any type of cache (and not have to create a notification for each type!)?

:)

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