<div dir="ltr"><div>Just to be a wet blanket.... (not really).  What happens when you have non-interconnected nodes and I wander from one area to the next.  Node A heard me 4 hours ago, Node B heard me 2 hours ago.... Node A is unaware that Node B heard me more recently... and both answer a query with different answers.  Worse yet, I've (fer instance) wandered back into Node A's range but due to a collision, Node A didn't decode me and still think's my last posit is 4 hours old when I'm actually sitting under the node.  This begins to sound like "the army way".... the right way, the wrong way and the Army way.</div>

<div> </div>
<div>Once, a long time ago, I thought caching positions was a good idea, but I came to see that it wasn't worth the effort.  No data is better than bad/old data - unless you flag such data so the end user can take the data with a grain of salt.  Now if you want to visibly depreciate a cached postion by marking it grey from the start, that might work... but we need someway to A)let the end user know that this station's info may not be valid, but is a best guess, B)Allow an actual position from the actual station to overwrite a cached postion display.  Of course none of what I'm suggesting is to be done on the networkside, it's all for the clients to display properly.</div>

<div> </div>
<div>Wes<br><br></div>
<div class="gmail_quote">On Thu, Jul 24, 2008 at 7:55 PM, Scott Miller <<a href="mailto:scott@opentrac.org">scott@opentrac.org</a>> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="Ih2E3d">> Anybody every thought about using something like a DNS server? Have one<br>> system that accepts inquiries about serial numbers and maps them to call<br>> signs. Since APRS acts a lot like a single broadcast domain clients that<br>
> overhead a request-reply could just cache the entry, minimizing traffic.<br>> The mappings could be aged out of the cache and/or reverified<br>> periodically. Then you only have one place to update the mapping. I<br>
> grant you doing this would require a change to all APRS clients but so<br>> would any major change.<br><br></div>Yes.  For position lookups and such, anyway.  I seem to remember I had a<br>working prototype based on BIND, but I can't remember what I did with<br>
the code.  I think it's probably on the old Win2k server in the rack in<br>the garage... I'll have to see if it still boots.<br><br>Or are you talking about on-air lookups?<br><br>Scott<br>N1VG<br>
<div>
<div></div>
<div class="Wj3C7c"><br><br>_______________________________________________<br>aprssig mailing list<br><a href="mailto:aprssig@lists.tapr.org">aprssig@lists.tapr.org</a><br><a href="https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig" target="_blank">https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Wes<br>---<br>Where there's silence, there is no Hope. </div>