If you make your input parameter to the existing daemon a DNS LOC record instead of callsign@gridsquare, you'd have the Lat/Long immediately available for updating the map, and we'd have the data for updating the DNS at some later time.
Remember that a DNS LOC record is a simple string consisting of <callsign> IN LOC <latitude> <longitude> <altitude> <accuracy> much of which is optional.
for example, a site located at the coordinates 52°22'23"″North 4°53'32"″East would send
'W1AW IN LOC 52 22 23.000 N 4 53 32.000 E -2.00m 0.00m 10000m 10m' or 'W1AW IN LOC 52 N 4 E -2m'
You could update the map from that. And later it would go into the DNS as w1aw.ampr.org's LOC record. All that would be necessary is for the map daemon to call a defined program with the record as an input parameter. That program (to be supplied later) would handle the DNS update, perhaps via some DDNS function.
(You could even make it backwards compatable by having the map daemon convert callsign@gridsquare to a LOC record. You'd lack the altitude part of the data, but you could assume it's zero for conversion purposes.)
The map would still be realtime, and the DNS somewhat historical.
See the wikipedia article https://en.wikipedia.org/wiki/LOC_record or RFC1876 for details on the record format. - Brian
On Thu, Jun 01, 2017 at 06:45:11PM +0300, Marius Petrescu wrote:
Let's do it... But how?
Re-register the DNS entries after DNS robot update? Ask Chris to get some new fields into the gateway tool and use that one to update the entries?
The idea is that there's some logistics in place. And even if that one will give us the locations. it is not live data. And the "live" is the nice idea.