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

Re: AO40rcv and the Kenwood TS-2000



> 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.

Isn't this a good example of specifying an abstract interface for the 
application protocols and then specifying different bindings to different 
transport methods.

A good way to go may be to define the application protocol using XML.

If we then stated that every application written implements the XML binding 
using a TCP/IP socket connection as the minimum,  this would allow interworking 
with any other apppication (written to the spec) running on any platform.

Now lets say that we define a binding of the protocol to RMI.  A Java 
application would implement the XML/Socket interface as required and could also 
implement the RMI interface thus allowing 2 Java applications to communicate 
that way rather than using the XML/Socket interface.

Other bindings could be specified for other inter program communications 
methods.


-- John Melton

                Principal Systems Software Engineer
        ((      Sun Microsystems,
      (|~~|     Solaris House, Guillemont Park,
       `--'     Minley Road, Blackwater,
                Camberley, Surrey GU17 9QG, England
       JAVA     Phone: +44 1252 421708  (internal ext 21708)
                Email: john.melton@sun.com




> To: amsat-bb@AMSAT.Org
> Subject: Re: [amsat-bb] 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
> me).
> 
> My sympathy (sort of) to all the electrical engineers on the list who
> thought that satellites and amateur radio were just about hardware...
> 
> -tjs
> ----
> Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
> To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org

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



AMSAT Top AMSAT Home