[aprssig] POI engine on APRS-IS
Lynn W. Deffenbaugh (Mr)
ldeffenb at homeside.to
Fri Feb 24 18:15:54 CST 2012
On 2/24/2012 7:00 PM, Bob Bruninga wrote:
> Quite the contrary. We only need one QRZ server independent of whether you
> are asking about an OBJECT or a STATION or anything else. You are simply
> asking QRZ about XXXXXX. The response would be the same. You'd get back an
> ITEM-in-MSG with the APRS -IS knowledge on that XXXXXX.
While I agree now with the general purpose QRZ server, I'm still
confused about your alternating "build it for the current platform"
versus "build for future capabilities". It would be far more
informative to do a requester-relative response to a QRZ query (MMM
miles @ ddd degrees) along with the queried station/object's comment
than to burp out a machine-readable, but nearly humanly useless
Item-In-Message response to a query.
The Item-In-Message is good as a response to the creation of an OBJECT
request as the user isn't really needing to know much other than "it
worked". But with a QRZ query response, one would assume that the
requester might be interested in where the station/object is actually
located relatively speaking. Now if the QRZ server implementer wants to
detect the requester's known platform capabilities, it could switch to
Item-In-Message if it is known to be understood, but for a usable
response, I'm thinking humanly readable/relative is a better approach.
> This is why it should be its own FUNCTIONAL service andnot just another
> format of a special case of something buttoned onto an OBJ server.
> The FUNCTIONS should be independent. Does not matter where they reside.
Once you explained it this way, I'm good with the QRZ and KILL servers
being outside of the OBJECT. You can query anything known to the APRS
system (well, at least known to the QRZ server) and you can kill
anything you can name (assuming reasonable protections applied by the
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
More information about the aprssig