[aprssig] POI engine on APRS-IS (no engine required!))

[Lynn W. Deffenbaugh (Mr)]

Nope, it won't work.  Consider this:

Mobile APRS radio user transmits a new wild-card Item-In-MSG and while 
that message is retrying, continues to hike down the trail.  The object 
moves with him/her until the message retries stop.

Another issue with that is that the Item-in-Message receivers MUST have 
heard the originator's position beacon to know where the item should 
be.   Worse, they may have heard a posit from the originator 10 minutes 
BEFORE the Item-in-Msg was received, again putting the item in the wrong 
place.

APRS messages need to not rely on 100% reception of packets to piece 
things together in all clients.  APRS-IS is MUCH more robust in this manner.

I do like transmitting an Item-in-Message back to the object originator 
as the acknoledgement of the object create, but I still believe an 
APRS-IS server is desirable to keep the object refreshed periodically 
for some period of time.

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

On 2/21/2012 10:42 AM, Bob Bruninga wrote:
> NO POI/ITEM/OBJ engine needed!
>
> The existing ITEM-in-MSG format (with the wildcard sender's position option)
> can do everything we need here.  We do not even need a special server..
>
> 1) As originally intended, the ITEM-in-MSG format allowed for sending an
> OBJECT to a mobile RADIO via the global APRS-IS system.  Thus, every client
> that has implemented the ITEM-in-MSG format will already see this new
> object.  The original intent of this was for the AVRS engine to be able to
> send a FREQ object to a called party so he could see where to call.
>
> 2) This new use of ITEM-in-MSG for the mobile or handheld radio to initiate
> an object can use the same protocol!  But to make it handy, we simply need
> to add the wildcard character * to indicate that the sender's own posit be
> used.
>
> Beyond that one change, there is no special engine required, no timing
> algorithms, no acks, no nothing.  If the sender wants so send an OBJEC To
> another person, the protocol does that well and the message will be acked.
> If the sender wants to send it so that it is seen on the APRS-IS or other
> local clients, then he can send it to ITEM, POI, OBJECT, DF or any other
> made-up address he wants and it will be transmitted 5 times and stop.  This
> is exactly what we want.
>
> Now, to give the sender some condifence, it would be OK for APRS-IS clients
> to offer an ACK service such as if an ITEM is sent to "APRS.FI" as the
> message address, then APRS.FI for example could send back an ACK to give the
> sender the knowledge that it has been captured.  Hopefully APRS.FI already
> does process the ITEM-in-MSG format though it will need to be updated to
> recognize the LAT and LONG wildcard.
>
> Done?
>
> Bob, Wb4APR
>
>
> -----Original Message-----
> From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On Behalf
> Of Bob Bruninga
> Sent: Tuesday, February 21, 2012 10:21 AM
> To: 'TAPR APRS Mailing List'
> Subject: Re: [aprssig] POI engine on APRS-IS (now the ITEM engine)
>
> HOW ABOUT THIS?
>
> We already have ITEM-in-MESSAGE since 2008.  We simply use it!  Then even on
> the first transmission from the radio, any client that already has
> ITEM-in-MSG will automatically plot it.
>
> The only modification to the ITEM-in-MSG is to let the POSIT have a wildcard
> option to be the SENDER's present position.
>
> EXISTING ITEM-in-MSG FORMAT:
>
> * Is normally sent do an individual recipient (so the object can get through
> IGates)
> * Normally has a full DDMM.mmN/DDDMM.mmW posit
>
> CHANGE:  If the POSIT field is replaced with */* then the posit date from
> the sender is used.  SO here is an example of placing the hiker FOOTSORE on
> the map.
>
> MESSSAGE TO ITEM.
>
> MESSAGE:  )FOOTSORE!*/*]CSE/SPD comments
>
> This is the existing ITEM-in-MSG format except the DDMM.MMN and DDDMM.mmW
> were replaced with *.  Notice how the TABLE character is preserved in its
> usual position too.
>
> IN this case, ANY existing object/item/df format may be used and we do not
> need to invent any new format.
>
> I will update the ITEM-in-MSG format document today to include this
> proposal.  Wow!
>
> Bob, Wb4APR
>
> -----Original Message-----
> From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On Behalf
> Of Bob Bruninga
> Sent: Tuesday, February 21, 2012 10:09 AM
> To: 'TAPR APRS Mailing List'
> Subject: Re: [aprssig] POI engine on APRS-IS (now the ITEM engine)
>
>> 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
>
>
> _______________________________________________
> 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
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>