[aprssig] spaces in object names

[Steve Dimse]

On Aug 12, 2009, at 10:51 PM, Pete Loveall AE5PL Lists wrote:
>
> Steve, I never said that jFindu "honored trailing spaces".  And that  
> was a private conversation which you misunderstood what I said.  To  
> be specific, I said -I- consider all 9 characters to be significant  
> per the spec.  However, what -you- assumed I meant was that I do not  
> trim trailing spaces in from Object names in the jFindu database.

OK, I still don't understand what you mean by considering all nine  
characters significant but you ignore trailing spaces. To whatever  
extend I failed to comprehend what you were trying to say then and now  
I apologize.
>
>> So here is what we still have to argue. I say that, for the same
>> reason trailing spaces should be ignored, only single consecutive
>> spaces should be allowed. ("A B C" would be OK, but "A    B" would
>> not.) The reason is that "A B", "A  B", "A   B", etc are too easily
>> confused in tactical situations.
>
> That is not the same reason trailing spaces should be ignored.  They  
> are two entirely different cases but you have failed to understand  
> that from everyone else's posts.

I've do not recall any explanation how it is different. Why trim  
trailing spaces other than to prevent confusion between "K4HG" and  
"K4HG     "? And exactly how is that different from differentiating  
between "A B" and "A     B".

> I am not avoiding it.  I am saying that you have a "paper tiger"  
> with this argument and that to consider otherwise is to ignore the  
> spec, the hundreds of clients in circulation, etc.

As I've stated several times, this is not about blindly following the  
spec. This is about settling the issue with a clear statement. It is  
in no way incompatible with the hundreds of clients. What I'm saying  
is simply a statement that object names should not contain more than a  
single consecutive space. This is entirely about the transmit side.  
Clients can add the code to prevent errors if they choose, but it is  
not incompatible with anything. It is simply placing an  
acknowledgement of the potential confusion between "A  B" and "A   B".
>
> Steve, do as you wish with findU.  If Bob feels strongly about this  
> to put your name mangling

I know you love to keep pushing this, but this is NOT what I am  
advocating, that was the choice 3 of 4 (and really 3 of 3 since you  
state I misunderstood your position on the trailing space). I am  
advocating the protocol state object names should not have two  
consecutive spaces. If you bothered to read what I write you would  
have known that.
>
>> Please tell me your answer to this question:
>>
>> APRS exists to provide real time tactical communications. Do you  
>> think
>> allowing "A B", A   B", and "A     B" to be transmitted as three
>> different objects improves APRS's utility in tactical communications?
>> Worsens it? Has no effect?
>
> Has no effect.  It does provide the ability to generate similarly  
> named objects (note I said "similarly", not "identical") to  
> represent different entities which I personally think enhances the  
> usability of APRS.

We disagree there. I believe that clear communication is important in  
tactical situations, and trying to puzzle out if "A  B" has one two or  
three spaces interferes with clear communications.

>  It is also backward compatible with most clients in distribution  
> which I think dramatically improves APRS' utility.

There is nothing incompatible with the statement that object names  
must not contain two or more consecutive spaces. Adopting that  
proposal reduces the chance for communications errors. I just cannot  
see a situation where having "A  B" and "A   B" as distinct objects  
would ever be considered an enhancement.

Steve K4HG