Jump to content

Why changed tag for mystery caches?


IDILIO49

Recommended Posts

Since today (11-06-2014) the GPX files generated (Pocket queries and gpx download from cache page) contained a different tag for type mystery.

 

Used to be: <type>Geocache|Unknown Cache</type>

 

and today is: <type>Geocache|Mystery Cache</type>

 

The immediate result is Garmin GPS doesn't show specific symbol in maps and menus for mystery caches, but a generic geocache symbol instead.

When activated a filter in GPS, mystery caches are never displayed as the filter works per positive (only active items displayed) and is not possible to activate mystery caches as they don't exist: http://www.garmindeveloper.com/apps/GarminCustomSymbols/CustomGeocacheList.txt

Link to comment

Since today (11-06-2014) the GPX files generated (Pocket queries and gpx download from cache page) contained a different tag for type mystery.

 

Used to be: <type>Geocache|Unknown Cache</type>

 

and today is: <type>Geocache|Mystery Cache</type>

 

The immediate result is Garmin GPS doesn't show specific symbol in maps and menus for mystery caches, but a generic geocache symbol instead.

When activated a filter in GPS, mystery caches are never displayed as the filter works per positive (only active items displayed) and is not possible to activate mystery caches as they don't exist: http://www.garmindeveloper.com/apps/GarminCustomSymbols/CustomGeocacheList.txt

 

Really? Never noticed that, of course I use GSAK.

Link to comment

We definitely need to know what the GPX will be calling that cache type, officially. "Mystery/Puzzle Cache" seems too extraneous; much preferred just "Unknown Cache", especially if it is still considered the 'catch-all'. =/

 

"Unknown" does seem to make more sense, especially if it's intended as a catch-all. From the icon and the cache type you don't know just what it's going to be.

 

It is odd that "nano" couldn't be introduced because of third party apps but this just appeared.

Link to comment

It is odd that "nano" couldn't be introduced because of third party apps but this just appeared.

Well, to be fair -- in a backhanded way -- I don't think this was intentional. My guess is that someone renamed "Unknown" in some list thinking it was just cosmetic, not realizing it would go into GPX files where outside applications would be expecting the old term.

 

I haven't noticed a problem with my PN-60. I don't know if that's just because my recent PQs just happened to be generated at the right times or because the PN-60 firmware just somehow avoids the problem. (My guess is that the PN-60 code is so old, it's still looking for "Mystery": wasn't that the original term for "Unknown" a few years ago?)

 

"Unknown" does seem to make more sense, especially if it's intended as a catch-all.

I always assumed the somewhat clunky "Unknown" was chosen for exactly that reason after careful consideration, so I was really surprised when they renamed it. I never really liked "Unknown" because it's so completely non-specific, but I accepted it as a reasonable choice all things considered.

Link to comment

My guess is that someone renamed "Unknown" in some list thinking it was just cosmetic, not realizing it would go into GPX files where outside applications would be expecting the old term.

I would certainly hope that isn't true. Anyone who doesn't fully understand the code that can impact a any *.gpx file that leaves gc.com shouldn't be touching that part of the code. One might also add that the comments in that code would have to either be pretty lame, or someone didn't take time to read them.
Link to comment

Well, to be fair -- in a backhanded way -- I don't think this was intentional. My guess is that someone renamed "Unknown" in some list thinking it was just cosmetic, not realizing it would go into GPX files where outside applications would be expecting the old term.

My take is that it was a very intentional change. They updated the knowledge books and changed Unknown to Mystery. I'm wondering if it is some ground work changes to get ready to introduce a challenge cache type with a new icon and designation. Or it simply could be change that seemed like a good idea at the time and since no one bothered to really review the change and the impact before it came out.

 

Considering the multifaceted use of the unknown type (puzzles, challenges, night caches, etc) unknown probably fits better than mystery. I mean, really, I don't consider a night cache a mystery, nor do I consider a Delorme square challenge a mystery.

 

Looking back, some choices made on designations and the like might not be the best fit for today's game like they were for the game back then, but things evolved. Unfortunately some of those choices are now cast into firmware and most of it can not be changed.

Link to comment

Well, to be fair -- in a backhanded way -- I don't think this was intentional. My guess is that someone renamed "Unknown" in some list thinking it was just cosmetic, not realizing it would go into GPX files where outside applications would be expecting the old term.

My take is that it was a very intentional change. They updated the knowledge books and changed Unknown to Mystery. I'm wondering if it is some ground work changes to get ready to introduce a challenge cache type with a new icon and designation. Or it simply could be change that seemed like a good idea at the time and since no one bothered to really review the change and the impact before it came out.

Without any more official announcements, we can only speculate. I think the renaming to "Mystery" is intentional, but the change in the GPX was not.

 

That's not important. What is important is : will the GPX be fixed, and if so, when?

 

Personally it doesn't affect me much (I only very occasionally copy GPX directly into my GPSr, and almost never copy Unknown / Mysteries. GSAK takes care of this inconsistency. And there's always :

 

sed "s/Mystery Cache<\//Unknown Cache<\//"

Link to comment

Seems like Mystery and Unknown are synonyms, so I don't know why one should be prefered to the other.

 

Some people may associate mystery with puzzle because of the use of mystery novel where the detective is "solving the mystery". You wouldn't say "solving the unknown".

 

Mystery is a noun, while unknown can be either a noun or a adjective. Perhaps it should be called a mysterious cache. Of all the cache types, traditional and virtual are modified by an adjective (and perhaps multi which is a prefix meaning multiple) EarthCache, Webcam Cache, Event Cache, and even Project A.P.E cache are all noun adjuncts. Unknown cache could be either and perhaps have different meaning depending on whether unknown is a noun or an adjective. Perhaps this is causing a problem in translating to some languange that has different words for unknown (n) and unknown (adj)?

Link to comment

The term used for the "?" cache type has evolved over the years and had resulted in mixed use throughout the site. In some places, it was "Mystery," in others, " Unknown," and in still others, "Puzzle." One of the larger requests on the old feedback site was to settle on a single term for these caches, and "Mystery" is what people indicated they preferred. It also has the benefit of translating more accurately worldwide. With the implementation of the new version of the Cache Submission Process (CSP), the time was right to consolidate the terminology and make it less confusing.

 

Unfortunately, in making this change, the team didn't account for the fact that the name in the database affects what populates the GPX and thus has an impact on third-party applications and hardware. We have always had to walk a tightrope between making any progress on features and being hamstrung by engineering choices from the past and often we stumble.

 

All that said, we are in discussions as to the best way to handle this now. No final decision has been made, but there will likely be two phases to correct this.

 

The first will probably be a short-term fix that will temporarily switch out the use of "Mystery Cache" to "Unknown Cache" in GPX files. "Mystery" will continue to be the way the cache type is referred to throughout the site, however.

 

The larger-scope fix will be to revive efforts to update the GPX schema. This work was largely completed a year and a half ago, but was mothballed for various reasons in favor of the API. It is clear that GPX is still a much-needed tool to the community, though, and so those of us on the product team would like to see the updated schema rolled out that will included much-desired benefits such as inclusion of favorite points, PMO status, et al. One of the other significant updates in the new schema is the use of numeric identifiers for various cache types, sizes, etc. Use of these numeric IDs would eliminate the risk of breaking third-party apps in the future whenever we need to make a simple term or capitalization change.

 

In the meantime, please bear with us as we work toward the best and most efficient solution for the current problem.

Link to comment

Since you're now knee-deep into how third parties interpret your stuff, why not include "Nano" cache sizes now? They're already being forced to adapt to the Mystery/Unknown thing, so might as well throw a new cache size at them as well, no?

Link to comment

Thanks for that very informative post, Moun10Bike. It's nice to see that communication from GSHQ is getting back to what it used to be.

 

I'm glad to hear that the importance of GPX has been recognized by TPTB. The API is certainly the future of the website, but GPX is still very much required for many people, so improvements to that would be very helpful.

Link to comment

I would certainly hope that isn't true. Anyone who doesn't fully understand the code that can impact a any *.gpx file that leaves gc.com shouldn't be touching that part of the code. One might also add that the comments in that code would have to either be pretty lame, or someone didn't take time to read them.

As a developer, I can tell you that it's not always clear what changes affect what code. In this case, I'm imaging that the code being changed appeared for all the world to be producing a string exclusively intended for users, so it would be easy to miss that it had been co-opted to produce the contents of that XML field.

 

Without any more official announcements, we can only speculate. I think the renaming to "Mystery" is intentional, but the change in the GPX was not.

Right, that's what I was thinking, and I consider this hypothesis confirmed by Moun10Bike's helpful explanation.

Link to comment
those of us on the product team would like to see the updated schema rolled out that will included much-desired benefits such as inclusion of favorite points, PMO status, et al. One of the other significant updates in the new schema is the use of numeric identifiers for various cache types, sizes, etc. Use of these numeric IDs would eliminate the risk of breaking third-party apps in the future whenever we need to make a simple term or capitalization change.

Yes! Thank you :) As a programmer, it always irks me having displayed text as unique data identifiers... data hog, as well as the risk of textual changes affecting data integrity. Also makes localization easier, swapping out alternate reference tables for text values, plus oodles of other benefits.

But anyway! :)

Thanks for the update

Link to comment

It is odd that "nano" couldn't be introduced because of third party apps but this just appeared.

Well, to be fair -- in a backhanded way -- I don't think this was intentional. My guess is that someone renamed "Unknown" in some list thinking it was just cosmetic, not realizing it would go into GPX files where outside applications would be expecting the old term.

 

... which raises all sorts of questions about what, if any, quality control and testing is done before a release.

Link to comment

Unfortunately, in making this change, the team didn't account for the fact that the name in the database affects what populates the GPX and thus has an impact on third-party applications and hardware.

I'd find this much easier to accept if not for the fact that we went through this only a few weeks ago with the renaming of Question to Answer and Stages of a Multicache....

 

http://forums.Groundspeak.com/GC/index.php?showtopic=322320

 

Still, thanks for the update, Moun10Bike. Good to see that GPX files are again on the radar for some love, too.

Edited by EngPhil
Link to comment
As a developer, I can tell you that it's not always clear what changes affect what code. In this case, I'm imaging that the code being changed appeared for all the world to be producing a string exclusively intended for users, so it would be easy to miss that it had been co-opted to produce the contents of that XML field.
As a fellow developer, all I can say is "OUCH"! Dependencies of this sort, especially those that impact the primary output for the majority of gc.com's paying users (premium usually = pocket query use = gpx files, whether directly downloaded or obtained via other 3rd party tools) should be very carefully commented in the code so that anyone who touches it understands the ramifications. Sorry - while "it's not always clear", there are times when there's no excuse for it NOT being clear. For example -- if you plan to #INCLUDE something critical, then the bit of code being 'included' had damned well better have comments that reference where it's presently being used to prevent surprises if that bit is changed. Or if all else fails -- there's always 'grep' or its moral equivalent to be SURE that the change isn't reaching into places that one does not anticipate.

 

That said, mistakes are mistakes. It's how you handle them that really matters. It sounds like we can expect a reversion to the prior string pretty soon.

Link to comment
As a developer, I can tell you that it's not always clear what changes affect what code. In this case, I'm imaging that the code being changed appeared for all the world to be producing a string exclusively intended for users, so it would be easy to miss that it had been co-opted to produce the contents of that XML field.
As a fellow developer, all I can say is "OUCH"! Dependencies of this sort, especially those that impact the primary output for the majority of gc.com's paying users (premium usually = pocket query use = gpx files, whether directly downloaded or obtained via other 3rd party tools) should be very carefully commented in the code so that anyone who touches it understands the ramifications. Sorry - while "it's not always clear", there are times when there's no excuse for it NOT being clear. For example -- if you plan to #INCLUDE something critical, then the bit of code being 'included' had damned well better have comments that reference where it's presently being used to prevent surprises if that bit is changed. Or if all else fails -- there's always 'grep' or its moral equivalent to be SURE that the change isn't reaching into places that one does not anticipate.

 

That said, mistakes are mistakes. It's how you handle them that really matters. It sounds like we can expect a reversion to the prior string pretty soon.

You make it sound like commenting code is a panacea. Google "commments are harmful" or "comments are evil" and you will find numerous essays by software experts who say that relying on comments causes far more errors than they prevent. . Using good coding practice and keeping the code clean and easy to read, is far more effective. Comments are often just plaing wrong and certainly they are rarely maintained with the rest of the code.

 

Separating GPX file creation from the display shown to the user on the website would be a far better approach. You could change what you display in website or app from what your put in the GPX and changing it in one place doesn't break it elsewhere. Of course if you want to change both it means having to change two places and more chances to introduce an error. There are always tradeoffs in software.

 

My guess is that this was simply a programmer who instead of adding a mapping from the database field to produce what they wanted to display, changed the database. I wouldn't touch the database unless that was absolutely necessary as that would obviously effect more than just what I was doing. You shouldn't need comments to tell me this. And if I was going to do this, the comments aren't going to stop me.

Edited by tozainamboku
Link to comment

Commenting code is certainly no panacea, but having followed up behind folks on a lot of projects, I can tell you that a much larger % of the prior owners of the code than I would like to consider provide almost no useful commenting at all to accompany their cryptic spaghetti.

 

You can only do just SO much with clever variable and function naming, and those don't fix problems like modifications to #INCLUDEs that get tweaked by someone who has no clue what modules are actually making use of that included code.

 

As for the separation of the creation of gpx files and what is displayed -- I suspect that at least in the case pocket queries, it's already that way. Two very different pieces of code accessing a common database, and you can bet the gpx generation does what it does with the content in a separate chunk of code.

Link to comment
As a developer, I can tell you that it's not always clear what changes affect what code. In this case, I'm imaging that the code being changed appeared for all the world to be producing a string exclusively intended for users, so it would be easy to miss that it had been co-opted to produce the contents of that XML field.
As a fellow developer, all I can say is "OUCH"! Dependencies of this sort, especially those that impact the primary output for the majority of gc.com's paying users (premium usually = pocket query use = gpx files, whether directly downloaded or obtained via other 3rd party tools) should be very carefully commented in the code so that anyone who touches it understands the ramifications. Sorry - while "it's not always clear", there are times when there's no excuse for it NOT being clear. For example -- if you plan to #INCLUDE something critical, then the bit of code being 'included' had damned well better have comments that reference where it's presently being used to prevent surprises if that bit is changed. Or if all else fails -- there's always 'grep' or its moral equivalent to be SURE that the change isn't reaching into places that one does not anticipate.

 

That said, mistakes are mistakes. It's how you handle them that really matters. It sounds like we can expect a reversion to the prior string pretty soon.

 

Exactly, the whole point of testing is to make sure somebody hasn't done something that breaks everything further downstream. It's pretty lame to have a developer just change something that breaks everything and then have a response that's little more than "sorry, we screwed it up, we'll try and fix it".

Link to comment

As for the separation of the creation of gpx files and what is displayed -- I suspect that at least in the case pocket queries, it's already that way. Two very different pieces of code accessing a common database, and you can bet the gpx generation does what it does with the content in a separate chunk of code.

If it wasn't before it certainly is that way now. <_<

 

My guess is that some programmer was told to change all the occurrences of Unknown on the website to Mystery. He found some query that read cache type from the database and displayed it on the screen. Rather than reading the existing value "Unknown" from the database and mapping it "Mystery" when displaying it, he went and changed the values in the database.

 

Now someone could have had a comment somewhere not to change the values in the database, but I'm not sure where. There were no database schema changes made, so you're not going to put it there. It would make little sense for the query code to say "Don't change the database because there are other queries elsewhere". Perhaps the code that generates the GPX file could have a comment that 3rd parties depend on the values of certain fields (particularly cache type). It certainly could have checked for unknown (pun unintended) cache types and reported them when generating a pocket query. But there are are already some cache types that aren't recognized by some third party tools, so I'm not sure if this would be the right approach.

 

I'm a bit more curious as to why the change didn't break the API that the apps other software uses. It may be the case that these map the cache type from a string to some enumeration, and whoever maintains the code that does this was told of the change to database and was able to coordinate the change needed for the API.

Link to comment
Unfortunately, in making this change, the team didn't account for the fact that the name in the database affects what populates the GPX and thus has an impact on third-party applications and hardware. We have always had to walk a tightrope between making any progress on features and being hamstrung by engineering choices from the past and often we stumble.

 

All that said, we are in discussions as to the best way to handle this now. No final decision has been made, but there will likely be two phases to correct this.

 

The first will probably be a short-term fix that will temporarily switch out the use of "Mystery Cache" to "Unknown Cache" in GPX files. "Mystery" will continue to be the way the cache type is referred to throughout the site, however.

Thank you, Mount10Bike, for the very valuable information. I know there are software developers out there who have been wondering whether to start the work to fix or whether to sit tight. Your message is that a reversion is in the works so that sitting tight makes sense.

 

What about, in the short term, having “Mystery” types be those puzzles for which the user has entered corrected coordinates, and using “Unknown” for ones that do not have that.

 

The larger-scope fix will be to revive efforts to update the GPX schema.

When the numeric cache-type IDs are implemented, I would suggest that a different value be used for those caches where the user has entered corrected coordinates versus ones where the user had not solved the puzzle.

 

As you can see already here in just a few posts, there is lots of interests in having the new gpx schema resolve various issues. Would you please suggest to Jayme H to open a thread in the User Insights forum to accept our input on what we users would love to see implemented in the new schema?

Link to comment

The fix seems quite simple to me:

 

If you are going to alter the GPX format then you also bump up the GPX version number, as was done to allow attribute information to be included or not. That way older devices continue to work as expected and newer ones can use the new format.

 

As it is now I am going to have to do a global replace every time I get new .gpx files.

 

Also, there is a huge QA failure here and this incorrect change should be reverted immediately.

Link to comment

The fix seems quite simple to me:

 

If you are going to alter the GPX format then you also bump up the GPX version number, as was done to allow attribute information to be included or not. That way older devices continue to work as expected and newer ones can use the new format.

 

As it is now I am going to have to do a global replace every time I get new .gpx files.

 

Also, there is a huge QA failure here and this incorrect change should be reverted immediately.

 

DId the GPX format change? Changing a value in an element that is not bounded (i.e.restricted to a specific set of values) is not a format or schema change.

Link to comment

DId the GPX format change? Changing a value in an element that is not bounded (i.e.restricted to a specific set of values) is not a format or schema change.

 

No but the only identifier for a cache type is a text string. Change the text string, and any app-specific functionality based on cache type breaks. That's the issue.

Link to comment

DId the GPX format change? Changing a value in an element that is not bounded (i.e.restricted to a specific set of values) is not a format or schema change.

No but the only identifier for a cache type is a text string. Change the text string, and any app-specific functionality based on cache type breaks. That's the issue.

Please don't bump the GPX version number. Your GPSr has a problem. Mine does not: it recognizes "Mystery Cache" as a synonym for "Unknown Cache". If you bumped the GPX version number even though no substantial change was made to the GPX schema, it will probably cause me a problem I don't currently have.

 

I have no idea why my GPSr recognizes "Mystery Cache", but one possibility is that "Mystery Cache" has always been an acceptable variation, and your GPSr's failure to recognize it is just has a bug.

 

I think the simpler fix is just to change the string back to "Unknown". I'm not sure why they're dragging their feet on such an obvious solution. Using an arbitrary string with historical significance for this one cache type makes a lot more sense than changing the field in all cases to an arbitrary (and completely meaningless) numeric code, the answer what Moun10Bike mentioned as the ultimate solution.

Link to comment

(fyi, I didn't advocate bumping the gpx number)

Technically, the schema hasn't changed, just the recognized data within the structure. How those values were used was external to the GPX XML format itself, so imo it's not a version change -- reading the GPX structure didn't break, just understanding the supplied content.

 

Nonetheless, every third party relied on that consistent unique identifier. Some (Including your gpsr, dprovan) handled that content better than others. Geosphere now has also been fixed to accept Unknown and Mystery cache values as referencing the same type of cache.

 

But when this app habit becomes the norm, there is a problem. There is no strict agreement about what text defines what cache type, just any developer's arbitrary mapping.

Cache type should be a consistent, unique identifier that never changes (without official announcement sufficiently ahead of time to developers), with its title separate and stored in a cross-reference list/table.

 

But anyway... =p

Link to comment

I'm quite surprised at how long it is taking to revert this one change. Some hardware and some 3rd party apps are breaking directly as a result of the change. It is well known what the change is. Why is it still broken?

 

I just created a PQ to check. It's still "Mystery Cache". It's been almost 2 weeks since it was first reported. Does Groundspeak not think that this is a serious problem, or is Groundspeak waiting to see if the problem will go away?

Link to comment

I'm quite surprised at how long it is taking to revert this one change. Some hardware and some 3rd party apps are breaking directly as a result of the change. It is well known what the change is. Why is it still broken?

 

I just created a PQ to check. It's still "Mystery Cache". It's been almost 2 weeks since it was first reported. Does Groundspeak not think that this is a serious problem, or is Groundspeak waiting to see if the problem will go away?

Right after the initial change they did revert for day or two and now reverted back to Mystery. I suspect it is going to be if we ignore it long enough the problem will go away. See the thread on charging VAT in Europe.

Link to comment

I'm quite surprised at how long it is taking to revert this one change. Some hardware and some 3rd party apps are breaking directly as a result of the change. It is well known what the change is. Why is it still broken?

 

I just created a PQ to check. It's still "Mystery Cache". It's been almost 2 weeks since it was first reported. Does Groundspeak not think that this is a serious problem, or is Groundspeak waiting to see if the problem will go away?

 

The change was a significant one - involving a database change to support an updated Cache Submission Process - with a fair amount of behind-the-scenes complexity. It was not something that could simply be rolled back with a wave of the hand. Our engineers have been working on a solution that allows us to keep the updated CSP and other related changes but replace "Mystery" with "Unknown" in GPX files. We expect this fix to be part of today's site update.

Link to comment

The change was a significant one - involving a database change to support an updated Cache Submission Process - with a fair amount of behind-the-scenes complexity. It was not something that could simply be rolled back with a wave of the hand. Our engineers have been working on a solution that allows us to keep the updated CSP and other related changes but replace "Mystery" with "Unknown" in GPX files. We expect this fix to be part of today's site update.

Appreciate the update, Moun10Bike. I know it does affect other things, but in such situations, most companies I've worked for will rather roll back new features immediately than break existing ones.

Link to comment

I'm quite surprised at how long it is taking to revert this one change. Some hardware and some 3rd party apps are breaking directly as a result of the change. It is well known what the change is. Why is it still broken?

 

I just created a PQ to check. It's still "Mystery Cache". It's been almost 2 weeks since it was first reported. Does Groundspeak not think that this is a serious problem, or is Groundspeak waiting to see if the problem will go away?

 

The change was a significant one - involving a database change to support an updated Cache Submission Process - with a fair amount of behind-the-scenes complexity. It was not something that could simply be rolled back with a wave of the hand. Our engineers have been working on a solution that allows us to keep the updated CSP and other related changes but replace "Mystery" with "Unknown" in GPX files. We expect this fix to be part of today's site update.

 

Was the change actually tested, or just thrown out there in the hope it would all be OK?

Was there any benefit to calling an "Unknown" cache a "Mystery" cache?

 

It's hard to take the company seriously when this sort of thing happens, especially when we couldn't have a "nano" size because it might break third party systems.

Link to comment

team tisri, you must have missed my earlier post here.

 

I did and it was a good explanation. It does lead me to wonder if all Unknown/Mystery/Puzzle caches are now going to be referred to as Mystery caches, does that mean the Challenge caches are going to get a new cache type and icon?

 

I might be a mystery why someone thinks it's a good idea to create a challenge to find 13 caches which have have numbers in their GC code with a checksum of 42, but I always thought "Unknown" was a better descriptor for that "catch-all" cache type.

 

BTW, nice to meet you the other day.

 

 

Link to comment

Please don't bump the GPX version number. Your GPSr has a problem. Mine does not: it recognizes "Mystery Cache" as a synonym for "Unknown Cache". If you bumped the GPX version number even though no substantial change was made to the GPX schema, it will probably cause me a problem I don't currently have.

Sounds like your GPS defaults to "Unknown", which in this case has worked out well for you.

 

Would you still feel the same if, say, they'd changed "Multi-cache" to "Multicache" and possibly made all your multis appear as unknowns?

 

However, this is all moot -- the change was accidental and (although I can't say I'm impressed with the fact that a rollback has not occurred nearly a week later!) Groundspeak are not intending for it to remain this way.

Link to comment

team tisri, you must have missed my earlier post here.

 

I saw that post, which doesn't answer the question of whether it was actually tested.

 

Unforeseen impacts are part of development, but that's why things need to be tested before they are rolled out. I just find it remarkable that something was rolled out that broke stuff when it's clear from the reports that a fairly small amount of testing would have identified the problems. I assume Groundspeak staff own a few GPS units between them?

Link to comment

Cachebox for PocketPC (whose last released version is from 2009 unfortunately, since the developers are doing Android stuff now) was affected both by the Unknown/Mystery dichotomy (luckily, it falls back to Unknown if the cache type is, pardon the pun, unknown) and – much worse – the stage renaming to virtual/physical stage. GPX import now throws a NullReferenceException, and Live API queries just abort after importing caches that do not use such waypoints.

 

So yes, changes like this *do* affect third-party applications (even paid-for ones like GeoScout, which cost me 20 GBP, which is quite a bit!), even those that use only published APIs. Do not break published APIs, and, if you absolutely must, do it in a way that keeps old applications running (e.g. offer a GPX version field for PQs and detect the client in the Live API and downgrade the protocol if the client is known old).

 

Thank you!

 

//mirabilos, also a programmer, lessions hard learned.

Link to comment

So yes, changes like this *do* affect third-party applications (even paid-for ones like GeoScout, which cost me 20 GBP, which is quite a bit!), even those that use only published APIs. Do not break published APIs, and, if you absolutely must, do it in a way that keeps old applications running (e.g. offer a GPX version field for PQs and detect the client in the Live API and downgrade the protocol if the client is known old).

 

//mirabilos, also a programmer, lessions hard learned.

 

I know that your last sentence is just an example, but in this case, the GPX schema didn't change (thus, it should not get a new version number).

 

What happened is the value of an element in the xml file changed. That element, by definition in the Groundspeak extensions to the schema, was unbounded. That means it could count contain *any* string. By tradition, the values produced out of the database was one of the existing cache types. Some applications were broken, because, they were written with the assumption that the value would only contain an enumerated list of values (Traditional cache, Unknown Cache, Multi-cache, Event cache...), presumably display the appropriate icon. Even if GS added a new cache type (i.e. Challenge cache), it would not require a GPX version change, because the schema allows for "any string" in that element.

 

Sure, it would have been nice if it as announced somewhere that the would be using "Mystery cache" instead of "Unknown cache" but the "bug" is not in the GS code (it is still producing valid GPX xml, according to the schema), but apparently several application/gps developers made the invalid assumption that the "type" field would be limited a specific list of values, and did not gracefully handle the exception when the field did not contain one of those values.

 

In any case, someone reported that it was working again with a recent PQ, so it sound like GS may have been able to deploy a hotfix.

Link to comment

Sure, it would have been nice if it as announced somewhere that the would be using "Mystery cache" instead of "Unknown cache" but the "bug" is not in the GS code (it is still producing valid GPX xml, according to the schema), but apparently several application/gps developers made the invalid assumption that the "type" field would be limited a specific list of values, and did not gracefully handle the exception when the field did not contain one of those values.

 

Sure, technically the GPX still agreed with the schema, but absent a definition of what is valid in that element, I'm not exactly sure what third party software is supposed to assume about the content.

 

How would you propose an app handled it if, say, "Traditional" was changed to "Basic" and a new cache of type "Potato" was simultaneously added?

 

You can handle it gracefully by either assuming a default (existing) cache type (wrong for at least the Potato) , or by creating a new cache type based on that field, but... how then should the app present the new types? At the very least, your Traditionals would now be indistinguishable from Potatoes....

 

The upshot is that when the only data available to the app to base a significant decision on is free-form, changes to that data are going to have unpredictable consequences, no matter how the app tries to handle it.

Link to comment

The problem is that cache types have different functionality - not just different names. So while the GPX itself wasn't "broken", it presented data with an arbitrary identifier, and no additional definitions; that necessarily meant that all 3rd party apps have to infer functionality based on that arbitrary identifier.

 

So, the GPX schema didn't change, but you could say the GPX format is incomplete. All parties, knowing this, should take that into consideration - 3rd parties should have fallbacks knowing that a new type won't be properly handled until more info about its nature is announced; and the 1st party should not presume that all 3rd party apps will operate just dandy with this very significant data alteration, since they don't provide any implicit definition of what the identifiers actually do or mean.

 

That said, they're working on it. So yay :P

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...