Jump to content

Rss Feed On "list Newest In <state>" Function


Lux

Recommended Posts

Actually I'm surprised that this has not be mentioned before (well searching on RSS* returns zero results and using google to search the site shows the same). But it would be nice to have an RSS feed on:

 

List newest in <state>

 

Is that something that is even being considered?

Edited by luxuryoils
Link to comment

I guess I misunderstood your question. The first time I read it, I thought you had two questions, one regarding RSS and the other regarding searching for newest caches. I didn't realize it was the same question.

 

Thanks for the smartass comeback though.

 

Jamie

Link to comment
I guess I misunderstood your question. The first time I read it, I thought you had two questions, one regarding RSS and the other regarding searching for newest caches. I didn't realize it was the same question.

 

Thanks for the smartass comeback though.

 

Jamie

Only frustrated. No harm intended.

Link to comment

Why the frustration? What is the problem you are trying to solve? PQ's and the web are clearly able to deliver the info you are after.

 

Even if RSS is a leaner protocol than html, having a number of rss-clients polling the feed every 10 minutes is clearly is going to stress the servers. Although I am sure your rss-reader will be configured to fetch the feed once or twice a day, I am pretty sure most other rss-savvy cachers will set their clients to fetch the feed much more often. And that will certainly load the servers.

Link to comment
Why the frustration? What is the problem you are trying to solve? PQ's and the web are clearly able to deliver the info you are after.

 

Even if RSS is a leaner protocol than html, having a number of rss-clients polling the feed every 10 minutes is clearly is going to stress the servers. Although I am sure your rss-reader will be configured to fetch the feed once or twice a day, I am pretty sure most other rss-savvy cachers will set their clients to fetch the feed much more often. And that will certainly load the servers.

There's multiple ways to provide the RSS feed to your users - static or dynamic. Dynamic is the equivalent of running a PQ and if the server had to build the RSS feed for each state (or region) then it would be rather resource intensive.

 

On the other hand, if the RSS feed was generated as a static file for the readers to retrieve either each time a new cache in the state/region was created or say every hour, there would be next to no impact on the app/database server and the web server would just return the static file. There would be next to no resource hit with this solution.

 

There's a TTL defined for a RSS feed and readers should honor it. If not, there's technical ways to stop people from hitting your RSS feed too often and sites such as Slashdot prevent you from doing it, blocking you for a rather extended period of time if you do retrieve it too often.

 

I think if there's a significant number of folks "previewing" their PQ throughout the day to see new caches that might pop up or accessing their state page for new caches (such as http://www.geocaching.com/local/default.as...e_id=31&x=4&y=5 for NJ), I don't think there would be much if any impact (and possibly a positive impact) if the RSS feed provided the same information.

Link to comment
I think if there's a significant number of folks "previewing" their PQ throughout the day to see new caches that might pop up or accessing their state page for new caches (such as http://www.geocaching.com/local/default.as...e_id=31&x=4&y=5 for NJ), I don't think there would be much if any impact (and possibly a positive impact) if the RSS feed provided the same information.

My suggestion is that the rss feed should be updated by the approval function. When a cache is approved it could rebuild the feed for that state. So minimal resources would be consumed.

 

The sad thing is people design ways around the system that consume much more resources such as previewing a PQ and GeoToad. Anytime you can present static up-to-date information you conserve resources by not building lists dynamically.

 

If you provide the information that people want in the least costly way, you will save resources in the long run. RSS is designed for this type of information dissemination.

Link to comment

Okay, I'm no expert in RSS feeds, (or anything else) but my guess is that people would want a list of new caches that would be ordered by distance from your location. It would seem that that would have to be dynamically created and would cause a load on servers.

 

GeoForse

Link to comment
Okay, I'm no expert in RSS feeds, (or anything else) but my guess is that people would want a list of new caches that would be ordered by distance from your location. It would seem that that would have to be dynamically created and would cause a load on servers.

I think a RSS feed by state would be great and could be very static, except when new caches are added in which case that one state's RSS feed would be regenerated.

 

Your assumption is correct if it was a personalized feed, but the original poster subject was by state.

Link to comment

OK, I think I have said something about this in the past... but I would love to put my thoughts in again.

 

RSS could be used for so many aspects of this geocaching.com. To be honest, could very easily save on bandwidth if was used widely. RSS is just good old text without binaries.

 

OK, some cool RSS features I would like to see.

- New caches based on area code or state, like mentioned.

- The obvious RSS of a cache and it's logs

- A feed for TB logs

- User activity. RSS a individuals logs.

- RSS Members attending an event.

 

If you can't tell... I really dig RSS :P

Link to comment
Yes. We have considered RSS feeds for cache information.

 

What specific problem are you trying to solve? I'll try to help you from that angle.

The nut I want to crack is knowing when new cache is released. Since it is a fairly uncommon event an RSS trigger would be a nice way to be informed. Currently, it seems, the GeoCaching universe of users are running PQ Previews several times a day to ascertain that information.

 

As I stated a few posts above; I could see a FIFO list, generated by the MOD approval function, that would push a new cache on the list and remove old caches from the feed. Since this information is to be used "real time" for possible FTF's, I would limit the feed to caches approved in the last two days. State wide is fine for the USA, not sure how your "nearest" function works for smaller countries.

 

But since a preview PQ does this, I'll burn the cycles for now. Thanks for at least posting in this thread.

Edited by luxuryoils
Link to comment
Yes. We have considered RSS feeds for cache information.

 

What specific problem are you trying to solve? I'll try to help you from that angle.

The nut I want to crack is knowing when new cache is released.

There is a separate project underway to provide an instant new cache notification feature for premium members. Perhaps this will address your need when it is implemented.

Link to comment
There is a separate project underway to provide an instant new cache notification feature for premium members. Perhaps this will address your need when it is implemented.

Well however they decide to provide the service. Just figured RSS would be the most efficient way. Thanks.

Link to comment

I would prefer a RSS implementation because it can be put on a local website's page for visitors to pick up on any new caches in the area. Many times such a person is disconnected from their email and would have only a few days old data at best. An RSS feed would allow them to pop into a local library and check for new caches.

 

I would think a RSS feed, in addition to an email feature, would the best way to go. No need to limit one's self to only one solution.

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