[aprssig] spaces in object names

[Pete Loveall AE5PL Lists]

> -----Original Message-----
> From: Steve Dimse
> Sent: Wednesday, August 12, 2009 9:30 PM
> 
> Hmmm, you were the one that said jfindu honored trailing spaces. At
> least I've convinced you of one way you were wrong!

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.  That assumption was incorrect.  I trim trailing spaces from Object names in the jFindu database but would not be adverse to going to the spec requirement of all 9 characters being significant if that was what was desired by all.

> Again, you have not bothered to read what I wrote. I agree that this
> is the least desirable choice (aside from your original position,
> which was that all spaces needed to be honored, including trailing
> spaces).

That was never my original position.  And has never been here.  And, yes I do read what you write (painful as it may be).

> 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.

> My argument has never been that it is not possible for hardware or
> software to handle multiple spaces. It is simple for me to implement
> what you now suggest, it takes the modification of a single character
> in a single regex.
> 
> My argument all along, the one you seem to be avoiding desperately,
> has been the problem lies in confusing users in tactical situations.
> Now that you have dropped your insistence on honoring trailing spaces,
> and I've accepted people want to include spaces, all we need to do is
> settle this issue of multiple consecutive spaces.

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.

Steve, do as you wish with findU.  If Bob feels strongly about this to put your name mangling (yes, that is what it is when you arbitrarily decide to modify a string because you don't like it) into his 1.2 addendum, then that is fine too because that is his document to do with as he chooses.

The objects are there and will continue to be there.  If someone else generates an Object with a name containing multiple embedded spaces, at least my software and most APRS clients currently installed will handle it correctly and not alter its name.

> 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.  It is also backward compatible with most clients in distribution which I think dramatically improves APRS' utility.

73,

Pete Loveall AE5PL
pete at ae5pl dot net