On 4/3/99 1:33 PM Mike Bilow ([EMAIL PROTECTED]) wrote:
>
>
>Steve Dimse wrote in a message to Mike Bilow:
>
> SD> The problem is that from practical standpoint you just can't do
> SD> that. There are too many people involved in APRS to start
> SD> over. We still get people who whine because they are using a 6
> SD> year old version of APRSdos, and it isn't working right
> SD> because the protocol changes. There are almost a thousand
> SD> owners of the Kenwood HTs that would need to upgrade. There are
> SD> more than a thousand users of the Mic-E and MIM that would need
> SD> to upgrade. How many thousands of TNC's?
>
>The first thing you do when designing any protocol is provide for a protocol
>version number, a frame length specifier, and finally an extension
>mechanism.
>This allows new innovations to be added to the protocol without breaking
>older
>implementations. Tying upper layer functionality to lower layer issues, such
>as whether the link layer is using datagram or virtual circuit mode, is an
>obviously bad idea. Protocols which have been properly designed from the
>beginning should be workable over nearly any reasonable transport mechanism.
>
Don't think I'm defending the APRS protocol here, because I think it
sucks, just not for these reasons. The APRS protocol runs fine on any
transport mechanism that is capable of handling ASCII. Most Internet
protocols, like http and telnet, have the same restriction. The upgrade
problem is only because I was responding to a proposal to completely
scrap the current APRS protocol and come up with something new. If they
threw out the IP protocol and started over, then all the routers on the
internet would need to be upgraded, wouldn't they?
> SD> One of the things you have to promise to become an "official
> SD> APRS software author" is never to release your source code.
>
>Really? That's insidious. What could be the point of that?
>
Per Bob, the primary reason is that if people could modify the code and
get on the air, the protocol would break down. And he does have a point.
Given the present state of the documentation on the protocol, and the way
he changes it when he feels the urge, it is hard enough for the four
major versions (Mac/WinAPRS [common codebase], APRSdos, APRS+SA, and
javAPRS) to keep in sync. The more authors in a situation like that, the
more chances for confusion. My argument that the answer is not to lock up
the source code, but rather to formalize the protocol, has fallen on deaf
ears.
Money is the other less often admitted reason he opposes source code
release.
Steve K4HG
