[aprssig] POI engine on APRS-IS (now the ITEM engine)
Lynn W. Deffenbaugh (Mr)
ldeffenb at homeside.to
Tue Feb 21 13:18:20 EST 2012
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
>
More information about the aprssig
mailing list