[aprssig] are write-only APRS-IS clients valid?

[Steve Dimse]

On Dec 2, 2013, at 12:34 PM, John Gorkos <jgorkos at gmail.com> wrote:

> My argument is that, if Pete is going to hold his software out as the de facto standard, and say "this is the right way to do X", and the APRS community wants to (or has to) use that standard, then the community ought to demand to see how it's done. Especially when the community is given comments like "That's just how it works." 

The code can be closed, but the algorithms cannot be. The APRS-IS has been that way since the start. The first APRS-IS was Dale Heatherington’s OS-2 IGate, which could serve packets received in the Atlanta area into my javAPRS software. Then I realized his server could feed Mac OS’s communication toolbox without modification, showing me live data in MacAPRS from Atlanta. Then I wrote a Mac program APRServ to IGate (1way!) the Miami traffic to the internet and combine it with data from Dale and another IGate in San Francisco. The first three IGates were running different software, written independently but sharing the algorithms. This is the way I think ham software should work. Open is fine if that is an author’s choice, but the algorithms must be open and shared. It is the open algorithms that make it work. And most of Pete’s documention on the algorithms is good - more than sufficient.

This “last heard” table Pete first mentioned in his last communication worries me a little. Google says the only mention of “last heard” on aprs-is.net (aside from two D-Star and javAPRS mentions) is in the javAPRSSvr manual where there is a LastHeardTime parameter, but it seems to work differently than the way Pete describes it. There is no mention that an internet packet overrides the last heard table, it is documented as a simple time out for forgetting about RF stations. Where that dup filtering is done makes a major difference and I agree that needs to at least be better documented, but better that the consequences of the decision be openly discussed.

> But what Pete is talking about is the core way traffic is handled in the core APRS servers.  It's a business-rules topic.  A protocol, if you will.  In that case, there can be no ambiguity.  It's a foundation to what all the other software authors in the APRS world need to have a core understanding of, and I'm arguing that a link to a website and a "that's how it is because that's how it is" is insufficient.

I absolutely agree. I’m assuming this is just a case of documentation not catching up to code, but given the fact that a widely implemented software feature can result in the non-delivery of packets to the RF network, I maintain it is a mistake as implemented. However, I can’t help but go back to an old TAPR expression “He who builds, rules.” meaning that the guy who has the chops to design the hardware got to make the important design decisions. Not long after I got active, the times they were a-changing so we altered it to “He who codes, rules.” And I certainly took advantage of that! 

I don’t begrudge Pete the right to code his software to fit his own vision of the APRS-IS. He needs to listen to people, or at least pretend to, but in the end the decision is his. If he gets it wrong then someone can make a competitor software to do it the way they think is right. 

Steve K4HG