[aprssig] spaces in object names
Curt, WE7U
archer at eskimo.com
Thu Aug 13 11:57:24 EDT 2009
On Thu, 13 Aug 2009, Pete Loveall AE5PL Lists wrote:
> We can attempt to warn against them in the spec but maybe a better
> statement would be "Creators of Object names should be aware of
> the visual ambiguity that certain character combinations may
> incur."
Agreed. It would be difficult to catch everything in S/W anyway.
Repetitive characters could be caught/flagged, mostly in GUI
client's as you stated but also in some text clients.
> "Is there a difference between
> 'AE5PL' and 'AE5PL '?" The answer is "Yes" according to the
> spec (which some have said we should not take so literally).
Are you talking above about two Objects, or a Station and an Object?
> The
> problem is we (myself included) as authors have -assumed- that we
> can consider stations and Objects as being the same. We display
> them the same. We store them in the same tables. We therefore
> equate Object names to station callsigns.
Depends. In Xastir we keep them in the same linked lists but set
flags to specify the type. We therefore do keep track of them
separately. I'd have to check what would happen if we get an Object
with the same name as a station though. It most likely would merge
the new data with the old record, therefore resetting the flags and
perhaps combining data that shouldn't be combined. If that case,
there goes the separately maintained lists...
Also, we trim trailing spaces off stations, objects, items.
> In fact, IMO, this has
> been a great disservice to the APRS community. An APRS station is
> an -active- transmitter (or APRS-IS client) that may have two-way
> communications capability. An Object is something created by an
> APRS station that has no APRS communications capability and may
> (quite often) represent non-amateur radio or at least non-APRS
> entities.
Perhaps Bob B. might weight in on this: I seem to remember Bob
stating that stations should be able to be taken over by other
stations, turning them into objects, etc, for tactical purposes.
The blurring in distinction between them might have been deliberate
from the get-go.
Bob?
> Now we are
> faced with how to make it a bit more palatable to the general user
> base. Do we do this by imposing draconian restrictions in a spec
> addendum that will have no effect on much of the software that is
> currently in the field? Or do we moderate the ideas put forth to
> best make use of existing clients while not imposing new
> restrictions on creative authors coming on the scene? Personally,
> I am a proponent of the latter.
Moderation is good. Bob B. was looking for some consensus from the
group on the matter.
> I
> think it will be a nightmare for Bob to have to continually modify
> his addendum every time someone says "this looks ambiguous on my
> display so we need to ban it or at least discourage it".
It's already "interesting" to have a PDF spec plus web page
addendums... One's that can be changed at any time and in fact have
been (In minor ways, I'm not pissed or anything).
I prefer finished specs myself. At least specs that have a rev.
number with each rev. unchangeable at the time it is published.
Makes it easier to code to and tell people what you're compatible
with.
> BTW, what can make this more confusing is if we consider Objects
> and Items as separate entities from stations in our display and
> storage, then we also have to consider Objects and Items as
> separate entities period because of the difference in naming
> requirements for the two packet types.
Side note: According to the spec addendums, Items have been
deprecated. Addendum 1.1: "Object Clarifications" and 1.2: First
section of bullets.
Xastir does enforce different naming requirements between the three
types, and yes, we do still support Items.
--
Curt, WE7U. <http://www.eskimo.com/~archer>
APRS: Where it's at! <http://www.xastir.org>
Lotto: A tax on people who are bad at math. - unknown
Windows: Microsoft's tax on computer illiterates. - WE7U.
The world DOES revolve around me: I picked the coordinate system!"
More information about the aprssig
mailing list