[aprssig] Throttleing EchoLink Objects

[Lynn W. Deffenbaugh (Mr)]

Steve Dimse wrote:
>
> On Jul 22, 2009, at 10:15 PM, Lynn W. Deffenbaugh (Mr) wrote:
>
>> Actually, there is a difference here.  When an EchoLink node dies, 
>> the APRS-IS feed will automatically quit sending the objects and it 
>> won't matter that the IGate operator is configured to get them to RF, 
>> they'll just quit.
>
> Let's back up. Are we agreed the point here is to get the beacon to 
> RF? If so, do you understand that in order for something on the APRS 
> IS to be gated to RF, the IGate operator MUST manually enter the 
> callsign of the blessed station or object?
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.
>
> So if I add a new echolink node, it will not appear on RF until the 
> local IGate operator finds out about it, and manually edits his 
> configuration file.
Agreed, unless we can dream up some other way of getting them out, say a 
trusted object source (ECHOLINK or KJ4ERJ-EL) and a local range filter 
configured ONCE when the IGate operator authorizes the gating.
>
> 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.
>
> Only for an IGate running javAPRServ. I run a very old version of that 
> program on findU, perhaps the new versions are capable of being 
> IGates, I'm sure Pete will help me out on this. Even if it is capable, 
> the majority of IGates are client programs like WinAPRS and UIView, or 
> aprsd. These require the operator to manually configure the blessed 
> station list. Nothing javAPRServ could do would control the output of 
> these IGates.
Yes, javAPRSserv does IGating.  That's what I'm running so I'm guilty of 
the carpenter syndrome.  I've got a hammer so everything looks like a 
nail.   Does anyone have any statistics on the IGate software 
distribution anywhere?
>
> 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.  
I'll take mine down if I ever hear of an FCC action against an IGate 
operator for passing through third party traffic.  (No, I do NOT want to 
open that can of worms discussion right now either!)  :)

We agree on a lot of points, and disagree on some.  That's the best way 
to arrive at a better solution that addresses, but may not completely 
satisfy, everyones needs.

Lynn (D) - KJ4ERJ