[aprssig] POI engine on APRS-IS (now the ITEM engine)

[Bob Bruninga]

> POI.  Also, can we make the [ts] (table symbol) allowed 
> to appear anywhere in the message and if not present, 
> a default symbol will be used.  Special characters are 
> harder to type than characters and if the sender 
> doesn't care, why put them through the agony.

I prefer the fixed format requiring the symbol in brackets as the 2nd word.
My assumption is that one only has to enter such an object once, and from
then on, he simply calls up his last transmitted object and cursors over to
only change what he needs to change to uplink the next object.  He should
never have to find the [ and ] keys again and for many applications, the
symbol will not be changing muchfor a given event.

> If the first word contains more than 9 characters, 
> a failure response is returned. 

Agreed.  In this case, the incoming messageITEM is ACKED and the error
message sent (and retried as normal)

NEW IDEA.  Instead of POI, lets make the engine simply respond to ITEM.
That is more in keeping with the existing APRS nomenclature (and more, see
below).

> ADOPT and KILL are reserved first words for the POI server.

ADOPT is not needed.  It is inherent in all APRS applications.  Any new ITEM
of the same name will automatically overwrite and adopt in other occurrence
of the same name.

The KILL cannot be a first word, since that is the ITEM name.  I think what
we need here is a MESSAGE ADDRESS reservation for KILL (just like OBJ).
Send the same message to ITEM and it makes an ITEM, send the object to KILL
and that results in a kill.

> If the first word is already known as a station or object 
> recently in APRS-IS at a different position and different owner, 
> then a warning is ...

Not needed as noted before.  These message objects are as legitimate as any
other APRS ITEM and so they are already handled properly by all systems.
That is, they overwrite the previous object/item.  This is firmly entrenched
in the APRS process.

> I'm trying to figure out an easy way to specify an object interval 
> and lifetime, but haven't landed on anything that is memorable 
> enough to actually work.  

Not needed.  The radios that will be used for this will transmit the object
(message) 5 times and then stop.  The ITEM engine takes each such
retransmission and does another ITEM generation.  The ITEM engine needs no
intelligence or timing.

Transmitting the same ITEM to KILL will do the same thing.  It will be sent
5 times to assure it probably gets received, and the KILL engine similarly
needs no timing of its own, but just generates the KILLED object.

Oh, and of course, the KILL and ITEM messages are never acked.  Though the
ITEM server can send back (and retry) its own message to the originator
indicating it has been processed.  This would be a message back to the
senders call using the ITEM-in-MESSAGE format!  Even though the present
radios cannot move these to their STATION list, they at least see that it
was processed, and the advangttage here is that ALL OTHER CLIENTS in the
local RF area, will also see the ITEM-IN-MESSAGE message and if they are
modern clients, then they will PLOT THEM!

In otherwords, the CLIENTS do not need any special OBJ recognizer (other
than implementing the ITEM-in-MSG already proposed).  They simply wait for
the OBJ engine to send back the ITEM-in-MESSAGE, and then they all show the
object!

Slick!

Bob, WB4APR