[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]

Re: AO40rcv and the Kenwood TS-2000

> Date: Thu, 05 Apr 2001 08:05:43 -0400
> From: Margaret Leber <maggie@voicenet.com>
> Subject: Re: [amsat-bb] AO40rcv and the Kenwood TS-2000
> Timothy J. Salo wrote:
> > Well, sort of.  I wouldn't call them particularly open or interoperable.
> They're open as all hell...the implementation details are published. For 
> "interoperable" we do have to ask "interoperable with what".

Interoperable between independent implementations that wish to
communicate with each other.  Again, I believe that the context of this
discussions is protocols for connecting pieces of amateur
radio-related software executing on different machines communicating
over an IP network such as the Internet.

The Java RMI protocol is tailored to the needs of the Java language.
Of course, the protocol could be implemented in some other language.
But, why use a protocol designed for a specific programming language?

> > A group of us tried using the Java object serialization facility to
> > transfer Java objects containing data between Java applications on
> > different machines...
> Well, while that does sound like a good bit of fun, it's hard to 
> understand why it was thought to be A Good Thing for whatever practical 
> job you were trying to do. It certainly ensured *oodles* of overhead for 
> no particular obvious benefit, and the devil's own time in unplanned and 
> undesirable interactions between the environments. As you discovered. 
> Shipping serialized objects isn't the same as RMI, of course.

Java Remote Method Invocation (RMI) uses object serialization to
pass arguments and return values.

> > Using Java RMI ...also pretty much assumes that the remote software is
> > written in Java...
> Or uses an ORB.

>From "The Java Programming Language, Second Edition"

	"RMI is explicitly designed to take advantage of having both
	client and server in Java."

Note that the spec also says that RMI requires that a security manager
be installed...

>  > ...A reasonable protocol would be language-independent.
> Well, "language-independence" is Microsoft's mantra whenever they're 
> Java-bashing, of course. I don't see anybody else in the software 
> industry getting all hyped up about it. MS also didn't get hyped about 
> it until they realized they weren't going to win fragmenting Java from 
> the inside, so it was time to start poisoning the well from the outside.
> Anybody who's written to Win32 in, say, COBOL or Fortran knows how 
> language-independant *that* is, of course. These days 
> "language-independance" seems to mostly be the battle cry of the C/C++ 
> crowd.

I don't think whining about Microsoft will assist us in understanding
the requirements for an appropriate protocol for interconnecting
amateur radio software.

> Be that as it may, a message-based protocol would be Mostly Harmless. 
> And RMI is OK too, *if* you're using a Java-based framework and have 
> archtectural control at both ends. In many cases you don't, of course.

Hence the use to the term "interoperable" (see above).

> > However, for
> > interconnecting amateur radio applications across a network, I recommend
> > that some simple (extensible) protocol be developed...

I stand by my original assertion (if anyone hasn't guessed by now...).

> I need to look at what the Internet Radio Linking Project people are 
> doing on this front too someday soon. http://www.irlp.net/

The task of the IRLP project looks interesting.  However, I probably
wouldn't use it as a model of protocol design.  If I understand correctly,
they are encoding commands as ditigized DPMF audio tones and are using some
special (and proprietary) hardware (the function of which isn't clear to

My sympathy (sort of) to all the electrical engineers on the list who
thought that satellites and amateur radio were just about hardware...

Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org