[aprssig] Throttleing EchoLink Objects

[Steve Dimse]

On Jul 22, 2009, at 10:54 PM, Lynn W. Deffenbaugh (Mr) wrote:

> Almost, I want to see the EchoLink nodes on BOTH platforms.  RF for  
> the mobile or non-Internet connected user, and -IS interleaved with  
> the remainder of the APRS landscape for trip planning in advance.  I  
> know the data is available elsewhere, but I would like to see it  
> integrated in one view.

As Pete summarized, we have had a lot of issues with putting stuff on  
APRS IS because it is convenient or cool. Unfortunately we are victims  
of our own success and we must be selective about what we put on the  
APRS IS. My criteria for what belongs on APRS IS are:

1. Data not available elsewhere. CWOP was here (and 2, 3 and 4) until  
it ran afoul of number 5.

2. Data somewhat useful to a lot of people. I place weather warnings  
in this category as well as the next two.

3. Data highly useful to some people. This would be messaging for  
example.

4. Data critical in emergencies. If there were, say another hurricane  
in New Orleans and someone uploaded Echolink status for nodes within  
100 miles I'd put that here.

5. Most importantly, data whose #1-4 advantages are not outweighed by  
the disadvantage of its volume.

Unfortunately when I look at this proposal, I see a maybe on number 3  
(I'd give you a yes if it automatically appeared on on every  
appropriate RF net, but requiring IGate configuration drops it to a  
maybe at best). It fails on all the others, especially number 5 even  
at the one hour time interval where you have taken any potential  
usefulness and diluted it greatly.

Sorry, but to me being possible, cool, and convenient are just not  
enough.
>>
>> Yes, you are right that if we choose not to clutter the APRS IS,  
>> the data will not reflect the changing status of the node, but with  
>> proposals for updates once every 10 minutes or 1 hour, it is not  
>> exactly like we are talking about real time information.
> I'm still not enamored of trying to reflect the realtime status  
> (Available, Busy, Conference) in the object.  I think we'd be ok  
> with just Online and completely suppressed for Offline.  If we  
> included the ABC status (+-= in the current proposal), that's a  
> bonus but a snapshot of the status at the time of beaconing.

The one possible justification that fits with APRS being a real time  
tactical system is to have this data be real time. Otherwise a user  
could go to echolink.org and print out a list of nodes along his route.

>> This is not a bug. An IGate operator is responsible for everything  
>> sent out on its transmitter, to pass off automatic control is not  
>> something I would ever want to see!
> Unless it is as I described above.  In order to do messaging, we  
> have to gate from Internet to RF.  If we put our licenses at risk,  
> so be it.

Fortunately for everyone, the creator and the leadership of the APRS  
IS feels a sense of responsibility for its users. We fight those  
things which can harm the internet system, the RF networks, and their  
operators. Understand this is not just a legal issue. We believe that  
every locality has the right to set its own priorities for its RF  
network; we do not dictate what must appear on their RF networks.  
Every locality is different, some areas are already grossly overloaded  
and this proposal could really harm them.

A mechanism created to allow internet operators (whether Pete, Bob,  
myself, or a popular vote) to choose what appears on local RF networks  
is very much against our principles. We all certainly try to influence  
what locals think should be on there, but that is VERY different from  
throwing a programmatic switch and making it so. I hope, even as much  
as Bob wants to see his present vision fulfilled, he would agree with  
this.

Steve K4HG