Jump to content

ClayJar

+Charter Members
  • Posts

    962
  • Joined

  • Last visited

Posts posted by ClayJar

  1. quote:
    Originally posted by Mr. Snazz:

    If they made the serial number a unique field, their database should reject the second submission of the data.


    It's not that easy, of course, but you know that. Still, they *should* fix the race condition. (If only it were as simple as a SQL-backed system so they could just use atomic transaction support.)
  2. quote:
    Originally posted by Elias:

    Are we sure people aren't accidentially hitting the "Post" button more than once?


    Okay, getting back to seriousness... What's happening is basically this:

    User hits the submit button.

    Nothing happens, or even...

    The browser times out.

    User sees the reply hasn't shown up.

    User hits the submit button again.

    (Possibly, repeat the timeout/wait.)

    Forums finally show the "thanks for the post" message.

    Back in the thread, the user now sees multiple posts... the timed-out ones actually worked... eventually.

     

    (Any news on the element? Jeremy's not given a final answer yet, and I'm dead in the water until he or you reply.)

     

    Oh, and Mr.Snazz: It does. This is a race condition.

  3. I have no numbers, but I know that lots of us made a note about the anniversaries (SA, cache placement, cache finding). Since the 3rd is on the Saturday this year, you'll probably see quite a few formal and informal cachiversary gatherings.

     

    By the way, feel free to trash out on Earth Day, but that's got nothing to do with the Cachiversary (other than the fact that lots of people do both).

  4. PalmDoc is close to the top of the TODO list, and HTML export might be right near that. The maps will have to be handled by some other program, but the GPSBabel plugin should make it easy to export to whatever you'd like.

     

    I'll start working on the export stuff once 0.1.31 is out, but until then, I don't want to start making major changes to the code (since I really want to release something quickly).

  5. In my Watcher settings, I have Virtual caches, Webcam caches, and Locationless caches filtered out of the cache types, and I have Micro and Virtual filtered out of the containers (i.e. sizes). When I'm looking at my Pocket Query GPX files, I only see the kinds of caches I really like. Of course, I also have a minimum terrain rating filter enabled... I'm me, after all. icon_wink.gif

  6. quote:
    Originally posted by GeoVamp:

    I feel like you are thinking that we are trying to drag people away from your site.


    Please don't think I'm offended or anything. I'm certainly not. I just wanted to point out that the "normal" chat has long ago reached critical mass. Due to the long history of the official chat and the large number of people who frequent it, just about any time you go there, *some* of us will be awake and chatting (except in the middle of the night, since most of us are in the US and the European and Australian cachers aren't always logged in).
  7. quote:
    Originally posted by GrizzlyJohn:

    Is there any one place where all of this sort of information and explanation can be found?


    Not yet, but I'm working on getting it all down in one spot. (Oh, and thanks for updating the containers with the correct complete list... I kinda forgot to post that.)
    quote:
    The one thing I am trying to figure out is how the available and archived attributes of the Groundspeak:cache element are used. Does a pocket query returned archived caches? So would this ever be anything other than false? What would be the use of the available attribute? When would that be set to false?
    Currently, PQs don't return archived or temporarily disabled caches. If Jeremy makes PQs with disabled or archived caches, then those attributes would be where you'd see that.

     

    Archived is, obviously, archived, and available is false if the cache is temporarily disabled by the owner.

  8. GeoVamp, are you ever going to come by the registration-not-required, long-standing fast, easy, and non-browser-based (unless you want to use the Java applet version) geocaching chat? At least drop by one of these Monday evenings for the Official Weekly Geocaching Chat.

     

    You can either use *any* IRC client to connect to irc.freenode.net and join channel #Geocache, or you can use the java applet at http://gcchat.clayjar.com/ (And when I say *any*, I include text-mode and graphical IRC clients on Linux, things like Snak on MacOS, Trillian, mIRC, and any other client.)

  9. Hope you're having an enjoyable Valentine's Day (or whatever else people do). The one "good" thing about holding back Watcher releases this long (this being the longest Watcher release delay ever, IIRC) is that I've had time to add quite a few things (and brdad has had time to find bugs in them).

     

    I've added right-click menus to copy cache names/links/etc (even pre-linked names and hiders for the forums). You can set north, south, east, and west limits in the filters (so you can, for example, make a rectangle or only look north of the arctic circle). You can filter by hider, state, or other fields if you want to for some reason. Watcher even saves the GPX files in their displayed order (so if people convert to PalmDoc or whatever, the order is preserved).

     

    And of course, the smart merge code is there. Once that is covered in the Groundspeak namespace, I'll be able to release 0.1.31. The funny thing is, I'm out of things to do until then. The only outstanding feature requests on my TODO list impact the core Watcher code far too much to begin them prior to releasing 0.1.31.

     

    So, when you get a moment, it would be very useful to know whether there will be a "//gpx/wpt/Groundspeak:cache/Groundspeak:exported" node. If you say that there will be one added, then I'll set Watcher to use that node and release 0.1.31; otherwise, I'll just have to stop working until something is worked out (or until I go back in and remove all the smart merge code). I don't want to be pushy or anything, but unless someone can come up with new features to add, I'm now stuck in the water.

  10. Well, if anyone's watching (er, sorry) this thread, I just figured I'd let you know that I'm still waiting on "exported" in the Groundspeak cache namespace so the smart merge code can be released. I've continued coding at about the standard pace, but it just hasn't been releasable because that change is still tied up somewhere. As soon as I can legitimately release 0.1.31, I will, and it should have enough new things to make it worth the wait.

  11. Just wondering if I'd managed to explain "exported" well enough... Lots of forum traffic and all, but I'm wondering if I should get back to work or wait a little while longer so I can release an 0.1.31 edition before beginning the next features.

  12. quote:
    Originally posted by VentureForth:

    Multiple queries will work great to also distinguish between multi, virtuals, traditionals and my hidden. I'll get one more query for later.... icon_smile.gif


    Actually, you can just get them all in one query and use Watcher to split them up, unless you like Mobi and want split Mobi eBooks... or you live in a large enough state that you need to split for the numbers. icon_wink.gif

     

    If you do want to refine your cache sets (or combine them), however, Watcher's there for you.

  13. quote:
    Originally posted by Jeremy (Admin):

    Last Updated would be fine now, as we already have that field available. That way you don't even need to bother replacing it if nothing has changed to that cache.


    Well, if lastUpdated is indeed available, it would be nice to have both:
    quote:


    Having lastUpdated would mean that you could tell whether the cache details were changed from one GPX to the next, which would be quite valuable information. However, we still need the field to store "exported" for the reasons covered above in this thread. To summarize:

     

    When you merge, lastUpdated will tell you whether the cache details in GPX #2 are unchanged from the cache details of GPX #1. What lastUpdated cannot do is tell you how long ago a given cache page was exported. In other words, if you have a cache page in your PDA, exported will tell you how stale that cache page is.

     

    I have caches that were lastUpdated over a year ago, but they were exported this morning. If I had one of those in my PDA, I would see from the exported timestamp that even though the cache page was lastUpdated a year ago, it's still freshly exported from Geocaching.com. lastUpdated is a valuable informative field which, if available, would provide useful information to GPX applications and users, but exported is the field that will monitor "cache page freshness" (allowing applications and users to know when the cache page was last known good).

     

    If you can add lastUpdated to the data returned by Pocket Queries, that would be *great*, but of primary importance is to have the exported placeholder in the XSD so Groundspeak-GPX-using applications can keep track of data freshness ("valuation date" as Markwell says it's called).

  14. quote:
    Originally posted by Jeremy Irish:

    I'll add a lastupdate field, but the question is... Is it good practice to change the version for the XSD or can I just add it on if it is an optional field?


    Just to be very specific, this is the "exported" timestamp, not "lastUpdated". The difference being that "lastUpdated" would be the timestamp the cache page was last updated/edited, but this is when the cache details were last exported, regardless of changes or the lack thereof. (It'd be great to know when a cache page was last updated, but that's something for April/May, I imagine.)

     

    As far as just adding it without changing the version number... Best practices dictate that one should change the version number whenever there is a change. However, since it is a completely optional field, and since it is extremely unlikely that anyone is using a cached version of the XSD to validate, it should be perfectly fine to just add the line.

    quote:
    Better yet, ClayJar, if you have a recommended format for adding to the XSD I'd love a suggestion. I'd root through the XSD but you already know how you want it...
    I ran this by a couple other guys to be sure I got it right, and the best way to do it is to simply add:
    <xs:element name="exported" msdata:Prefix="Groundspeak" type="xs:dateTime" minOccurs="0" />
    right before the final seven lines from the bottom (just below the travelbugs block). If you wanted, you could add msdata:Ordinal="10" right after minOccurs="0", but we don't see why you'd bother.
  15. I see where you're coming from, and managing extensive cache collections is one of the things that Watcher is intended to help people do.

     

    (Note: Until Jeremy gets around to replying regarding what Groundspeak GPX node to use for per-waypoint exported timestamp, it's still missing one *very* important ability -- smart merging -- but I'm sure he'll reply soon.)

     

    What I do is run full-state queries on many states. If the state has a very large number of caches, I'll usually split it by type -- it's trivial to put the pieces back together in Watcher. I run the queries about once a week, depending on if I know where I'll be going (then I run an extra for that area). Editing my five PQs to get different cache sets each run is a bit of work, but I got used to it. (For what I can do with it, it's no big deal at all.)

     

    Right now, I have to use a separate utility to convert to HTML or PalmDoc or whatever (GPSBabel supports everything but PLGR, I think icon_wink.gif), but that's being worked on. The ability to filter a cache list by N/S/E/W bounds is coming soon, and I just figured out how I can add special filters for those who want to filter out a country or state or hider or whatever (those were hard to figure out, since they're, in effect, free-form text fields).

     

    Anyway, if there's some way that I can update Watcher to make your life easier, please, by all means, let me know. I'm adding features at a fairly high rate, I'm told, so if it's a good idea, it'll be in there in not long at all. I want to do everything I can to make geocachers' lives easier and more full-featured. (You can reach me in the official geocaching chat almost every evening, and you can e-mail me at GPS@C___J__.com (ClayJar, that is). Or, of course, you can just reply here.

     

    -ClayJar

    Watcher Developer

  16. Okay, Watcher 0.1.31 is ready except for knowing where to put the Exported timestamp for the smart merge code. Actually, though, you don't even have to update the XSD right away, since Watcher ony parses the GPX XML, it doesn't validate it. I just need to know where to put it.

     

    Is something like "//gpx/wpt/Groundspeak:cache/Groundspeak:exported" good, or do you want it somewhere else? (I can't do any more work without either knowing this answer and releasing 0.1.31 or backing out the smart merge code... and I hate being bored.)

×
×
  • Create New...