[aprssig] spaces in object names (meaning)

[Steve Dimse]

On Aug 13, 2009, at 1:35 PM, Pete Loveall AE5PL Lists wrote:

> As I indicated in the post you referenced, IMO your interpretation  
> (which I do not dispute) is a great disservice to the APRS  
> community.  The protocol has built into it the very basis of all  
> tactical communications that I am familiar with (which extends well  
> beyond amateur radio).  That basis is summarized in the following 2  
> statements:
>
> Show me what my active entities are and which ones can I communicate  
> with immediately.
> Show me what are created entities and which ones are time-sensitive.
>
That is not the way someone participating in a tactical situation  
views things. He wants to know the current situation. If you have an  
object named "LEAD" and a station named "LEAD" both on the map, even  
if they are identified as an object and a station, there is confusion.  
If there is an object called "RESCUE 1" and another called "RESCUE   
1", there is confusion. Confusion is bad.

None of what Bob and I are saying affects the way you choose to  
display this on an individual client. If you want to write one that,  
say, prepends a * before something that does not have the ability to  
receive message you can do so. Most clients have some way to convey  
this information, perhaps by a popup bubble, a status bar, or another  
window that appears when you click on a symbol on the map. The  
information and methods to display is up to the client author.

What must be implemented for the use of APRS in tactical settings is a  
flat namespace. This is mentioned, though not rigorously, in the spec  
in regards to objects not belonging to the person that sent them, I  
can kill or move an object you created.

I agree with your idea that there should be something in the spec that  
users should avoid the use of confusing object and item names for  
clarity, and special symbol use should be minimized, as much as  
anything, because testing of bizarre objects names in most clients is  
far from rigorous. We've heard for example that aprs.fi cannot handle  
commas. I'm sure there are characters that will cause some problem or  
another with findU. There may be some in jfindu. Most clients are not  
subjected to rigorous testing.

A perfect example is the thing that touched this off. The removal of  
all spaces from object names has lurked in findU's parser since it was  
first written, nearly 10 years ago, it it is just now that the issue  
comes up. Yes, I know you are so much better than me, you do  
everything perfectly. I'm not like that, thank God!

I'm still pushing for explicit prohibition of more than a single  
special character in a row.

Steve K4HG