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

[Lynn W. Deffenbaugh (Mr)]

On 2/21/2012 10:09 AM, Bob Bruninga wrote:
> 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).

Shorter is better, as is using names that John Q. Public encounters in 
other similar uses.  ITEM is APRS-esque.  POI is GPS-esque.  My vote 
still goes for POI even if Item-as-Message is used in the implementation.

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

Adopt is inherent in some/most APRS applications, but is particularly 
detrimental in the UI-View implementation which REPLACES the local 
DEFINITION (not display, but definition) with whatever is received from 
the outside.  So, if there's a UI-View instance that has had an object 
called PLACEMARK and has been beaconing it for years when someone sends 
a PLACEMARK to POI, BOOM!  That years-old definition is GONE from the 
UI-View instance and the inadvertent adopter of the PLACEMARK is likely 
to get some hate mail from the original "owner".  Hence my suggestion of 
explicit adoption intention but automatic update of objects if the new 
definition is coming from the current owner.

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

KILL and ADOPT could be the first word, if we make them reserved object 
names for the POI server.  Rather than chewing up seemingly unrelated 
message-addressible namespace for sometimes use, if we can't put the 
command before the object name, then can we make it POIKIL as the 
message destination to kill an object?  At least the names will tie 
together when people are looking for POI activities.

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

Firmly and dangerously implemented in at least one APRS client.  We have 
a chance to avoid stepping on planetary toes with local usage, so why 
not take it?   Adoption isn't done that often, but choosing a good local 
object name currently recommends that you use an APRS-IS-based client to 
check if it is used anywhere on the planet.  That's not something easily 
done with an APRS radio, which is why I still contend we need an 
EXPLICIT adoption indicator if the object already exists under a 
different owner on the APRS-IS.


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

IMHO, it would be good for the object to continue for some period of 
time to allow for reception by clients that may not have been online (RF 
or -IS) at the time the object was originally created.  Otherwise, you 
might as well just throw a message to ALL out from the radio that 
contains some arbitrary information.  The only thing your POI server 
would be doing is attaching coordinates.  It can be SO much more useful 
if it records the object and keeps it "fresh" for some period of time.

With some upcoming IGate capabilities, those object may be automatically 
gated from -IS to RF during that freshen time period as well, allowing 
even the local RF users that came late to the party to become aware of 
what has gone (recently) before.


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

POIKIL, please, not a seemingly unrelated KILL


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

If the client puts a sequence at the end, they get ack'd.  That's the 
APRS messaging spec.  No sense in retransmitting a message to a server 
if the server received it and has issued the ack.  A Reply-Ack may also 
come back on the response message (be it Item-In-Message or a report of 
a problem like no known coordinates), but if the message has a sequence, 
an ack will be automatic.

Whether or not other modern clients display Item-in-messages that are 
not addressed to them is up to the client author, just like whether or 
not other directed messages may or may not be captured and displayed.  
Let's not extend other assumptions into other non-POI areas unnecessarily.


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

You have my 100% agreement on the success response from the POI 
generator being an Item-in-message format.  That's a great use of the 
function.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

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