[aprssig] EchoLink APRS-IS Ojbects Mothballed

[Robert Bruninga]

> EchoLink APRS-IS Ojbects...
> 
> Have you looked at the Item-In-Message 
> format proposed for APRS 1.2?  
> http://aprs.org/aprs12/item-in-msg.txt
> 
> Then as APRS clients get upgraded to support 
> it (I'm planning to in my APRSISCE for Windows 
> Mobile), your server will be ready to deliver!

Yes, that is exactly what that format is proposed for.

However, Since the Yaesu and all existing D7 and D700's are
fixed programmed, they will never be able to see these objects.
And it will be a year or more before the new Kenwood or other
new radios...  And same goes for Uiview Igates which will never
be upgraded.

So, I'd prefer a *will-work-now* approach to this project.

Someone needs to write a simple stand-alone Igate code.  In this
Igate code is where this database access goes to respond to
queries of the type mentioned.  In fact, then it would not need
to even have the query response system, it would be able to just
refresh the status of its local EchoLink and IRLP nodes and then
it would SERVE them out to the local area as standard objects
that are fully compatible with all existing and future radios.

This new Igate code would be user friendly and allow for
provision for all the other local info services:

1) Local Echolink and IRLP node objects
2) Local Traffic speed objects
3) Local Meeting and Net annoucncements
4) Satellites In view for mobiles.
5) etc...

!AND! Every object above would have its OWN PATH.  Hopefully all
the paths would be simplex direct and this Igate be at a high
location.  But failing that, it could have a separate 1 hop path
to ONLY the digi that best covers where that object needs to be.
2  hop paths would not be allowed for the objects to avoid the
temptation of ego's in creating local spam beyond their
immediate area.

By generating these locally, then we have local control.  And
the code as an Igate could be very universally and consistently
used Across all of APRS.

Bob, WB4aPR