Jump to content

Whither Cache_logfind.asp ?


robertlipe

Recommended Posts

I had a handy-dandy logging interface to this site that required as close to ZERO page loads as possible that, at my stride, could coherently log about 6 caches per minute. (I'm a decent typist and don't cut/paste logs.) It has worked flawlessly for probably 2,000 logs. It was crotchety the last time I used it, but appears to be flat-lined right now.

 

http://www.geocaching.com/seek/cache_logfind.asp was a very simple interface: a form that, once logged in, could be posted back with the three required <INPUT>s populated - log type (which I could default sensibly) log date (which defaulted to my previous log date since I, like others, tend to cache in batches), and log text - and simply await the response. Now that page silently -and slowly- redirects to http://www.geocaching.com/my/ and the provided log page uses http://www.geocaching.com/seek/log.aspx which appears to be more .net joy. Unfortunately, this appears to require a VIEWSTATE that, unlike most of the pages, isn't merely a 1,920 byte constant (sigh) indicating that you're logged in, but apparently contains the cache ID.

 

The punchline is that I no longer see an easy way to squirt a log directly into the system without roundtripping a server transaction to get this viewstate which seems to contain the cache ID in the most obtuse manner possible. Is that an accurate reading? Is the formula for producing a viewstate from a login/cache id pair available? Better yet, is there a way to inject a log without this roundtrip? Talks about future 'web services' are a distraction as the data should come completely from the client side: "I want this log text on this day for this GC#".

 

Has something just subtly changed that's accidentally broken this functionality or is this some piece of a larger play? Geek-to-geek, is there an efficient logging interface available now?

 

And before anyone that doesn't understand computers screams about me being the one to ruin the site every Sunday night with silliness about server load, my logging interface was MORE efficient as I didn't have to load each cache page just to get to the "log this cache" page and I didn't have to either bounce back to "find nearest" or "seek" to get to the next one - I could go straight from cache to cache with exactly one page going from my computer to gc.com and only one page (the "you have logged..." ack) coming back. Both were very simple pages. Besides, I know not to log on Sunday nite anyway...

Link to post

Felt this thread could use a nudge, since there's been no reply and I'm becoming interested in this stuff too...

 

Better yet, is there a way to inject a log without this roundtrip?    Talks about future 'web services' are a distraction as the data should come completely from the client side: "I want this log text on this day for this GC#".

No one ever said that web services were strictly for querying information from a remote site. They can also be used to submit information (more than one weblog API works this way).

 

I'm personally hoping that the ability to submit a log is part of the web services to (supposedly) come, as people have been asking about the ability to upload logs from CacheMate (or a plugin) to the site for a while, and I refuse to try and reverse-engineer the site to do that the hard way, mainly because of the problems you've run into.

Link to post

Yes, but it was buried in a topic. But Maeglin seemed to know this already since he referenced the web services concept in his post. Are you just looking for an update? If so, there is nothing new to report. Workin' on it.

Link to post

Well, if you check the dates, that wasn't announced (if that's an announcement) when the question was originally asked (and ignored). It sounds like it could be at least a partial solution.

 

From the description given, it's hard to imagine it'll approach the simplicity of the old way (that I could do in two lines of code) but I'm quite willing to read the info once its available. I suppose since the simple way went away, the options are to either use the existing logging interface, write a wrapper to it and live with the silly viewstate transactions, or wait for a a future service that may or may not help.

Link to post

Robertlipe, Jeremy also posted on pretty much the same subject on April 7th and April 12th - very close in time to your topic being posted. IMHO, your topic was ignored only in the sense that he didn't post the same thing repeatedly in any topic where it was responsive.

 

I do hope that you choose to participate actively in the Developers' Sandbox when it is up and running. Solutions like GPSBabel are a godsend to geocachers (many of whom don't even realize that they're using it, albeit behind the scenes). Perhaps you can bring your considerable talents to bear on the simplified logging process as well. Trust me, I will stay the heck out of *that* sandbox!

Link to post
Yes, but it was buried in a topic. But Maeglin seemed to know this already since he referenced the web services concept in his post. Are you just looking for an update? If so, there is nothing new to report. Workin' on it.

I didn't know about that particular post, because it was buried in that topic. The references to web services I was making were to posts made around this time last year. I'm looking forward to it being operational, though, esp. since the logging functions will be a part of it :ph34r:

Link to post
Robertlipe, Jeremy also posted on pretty much the same subject on April 7th and April 12th - very close in time to your topic being
Huh. You're right. If I would have dug through every post on the site, including other forums in unrelated threads, I could have seen a hint that a replacement for the missing functionality was being thought about. Surely you'll understand that was less than satisfying.

 

I do hope that you choose to participate actively in the Developers' Sandbox when it is up and running.  Solutions like GPSBabel are a godsend to geocachers (many of whom don't even realize that they're using it, albeit behind the scenes).

 

I assume the site knows how to find me when this is ready. (Assuming I've not totally cheezed Jeremy and Elias off by then and been banned or something. :ph34r: ) I do have a fear that it'll be exactly as you describe, though; the developers will be invited "when it's up and running" instead of being consulted up front. I can hope that 18 months of suggestions on the PQs from the likes of ClayJar, Lil Devil, rickrich, ClydeE, and others have been captured and will see daylight. (It's an interesting and often unnoted artifact of the geekiness of this hobby that we have so many developers donating substantial talent for free to improve the hobby...)

 

Reminds me of one of my favorite Rita Rudner lines - "It wasn't that nobody would invite me to the prom; it's that no one would tell me where it was..."

Link to post

The Sandbox will initially be created so we have a centralized location to discuss developer issues. We'll also communicate changes before they happen, which we don't currently do. We'll propose changes and have a back and forth before implementing them.

 

As with the previous message, some responses are buried within other topics, which is currently a poor process. I'm trying to rectify this so please cut me some slack.

 

Robertlipe, you're the last person I'd ban from the forums or anywhere else. You've provided countless contributions for as long as I can remember.

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