[aprssig] OBJ engine on APRS-IS (Functions)

[Bob Bruninga]

I disagree strongly.

> I disagree on multiple destination addresses to talk 
> to the same server. ... OBJECT - to define them, 
> KILL - to kill them, and QRZ - to query them.  The 
> object server is a single server and should respond 
> to a single message destination name, OBJECT.

Why?  Any programmer can easily handle responding to the three different
FUNCTIONS.  I would rather him spend an extra 3 minutes during coding then
doom the thousands of users forever to have to edit in the words QRZ and
KILL into new messages.

> Commands to said server should be in the message content.

Disagree completely.  The message content *does-not-change*  There is no
reason to force users to have to re-edit message content when all they want
to do is to KILL an existing object.  They simply call up their EXISTING
object message, change the send address to KILL.  That is much more logical
and requires no editing of yet another message format.

> It's almost as easy to poke the button to move from the 
> OBJECT destination to the content field, cursor past the 
> object name, enter *KILL* and then DELete the remainder 
> of the message and sent it.

The key word there is "almost".  That violates the objective of making this
process as simple as possible for the sender.  And what is the benefit of
making this harder for ALL users?  So some  programmer can save 3 minutes of
coding time?  I fight for the end users.  That is what counts.

> And I state again, please don't assume that all APRS messaging 
> RF stations are the current crop of radios.

I disagree strongly.  As long as there are 10's of thousands of EXISTING
radios out there, it is my number one imperative to make sure that any
tweaks to APRS that programmers make for their own simplifications or
aesthetics do not obsolete or burden existing users.

> TT4s do messaging with displays and keyboards and 
> I don't know if they have message recall. Tracker2's 
> do messaging from Garmin Nuvis and I'm pretty sure they don't
> do any message recall.  And the new YagTracker also does 
> messaging (I think) but I don't know about recall/edit/resend 
> capabilities there.

I do not see the point at all.  You are willing to sacrifice user
operability of 10's of thousands of existing users who have invested
millions of dollars in their radios which can do message editing and resend
for a few potential devices that might lack even a basic editing capability?
Such logic astounds me.

> This is a single OBJECT server, and I believe it should 
> remain a single message target.  Otherwise we're setting 
> a precedent that servers can consume any number of message 
> destinations that may be so generic (like QRZ/KILL) that 
> their use for one function precludes there use from
> future servers where they may make more sense.  Namespaces 
> are precious and limited resourses, let's not squander them unnecessarily.

The NAME space is a FUNCTION target not a given "server" target.  If the
function is to create an OBJECT, then we should use the OBJ (or OBJECT)
target.  If the function is to KILL an object then the word KILL makes
logical sense.  KILL is an APRS well defined function.  It is not
squandering the term to use it as it was designed.  Same goes for the QRZ
generic address.  The FUNCTION is to ask about the <name>, whether it is a
station or object, it does not matter. In fact, I am surprised that such a
FUNCTION address does not already exist.  If not, it should on its own
account.

Sending a MESSAGE to QRZ with the first word as the word in question seems
to me to be a perfectly good use of that function.  It returns the same
information whether it is a STATION NAME or an OBJECT NAME (both are
synonymous in APRS).  And there is nothing that even requires these three
functions to be supported in the same physical "server".  They are
functions.  And so they should each have their own separate FUNCTIONAL
address.

My goal is to minimize the SENDER's effort (on a tiny keypad).  Allowing the
message content to remain the same and to only change the sending address to
get the different function is the most  user friendly approach.

Bob, WB4APR

On 2/24/2012 9:03 AM, Bob Bruninga wrote:
> Please use the APRS standard for LAT/LONG.  DEG and decimal minutes...
>
> 00:38:15<  Obj: OBJECT Created at 29.122 / -80.987
>
>> It will even let you kill an object but ONLY IF
>> YOU ARE THE OWNER! By using the "<OBJECT NAME>  *KILL*" command.

> I object strongly. (Pun intended). The proposed format is for the KILL
> function to be implemented by sending the SAME message text that created
the
> object to the KILL address.  This is for ease of use of the SENDER.  All
he
> has to do is call up the old object message, change the TOADDRESS to KILL
> and it will send the KILL message.
>
> Introducing yet another format is not a good idea in my opinion.
>
> There is a lot of kibitizing on this project and I hope that only those
who
> have complete and frequent experience with sending messages from the APRS
> HT's are contributing.  That is the only intent of this function.  So if
> every aspect of this project is not totally committed to simplifying the
> process on these HT's then we are missing the mark.
>
>> ALSO... (just for S&  G's) anyone can query the existence
>> of an object by using the "<OBJECT NAME>  *QTH*" command...
> Same comment.  Send the<objectname>  message to the message address of QRZ
> makes more sense to me.  This way we have a consistent set.
>
> Send to OBJ to create the object.
> Send to KILL to kill the object,
> Send to QRZ to see who owns it.
>
> Bob, WB4APR
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>


_______________________________________________
aprssig mailing list
aprssig at tapr.org
https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig