[aprssig] Rant - Cross platform portability

[Gregg Wonderly]

Dave Baxter wrote:
> However.....   Of the Ham population, who actually program anything
> significant, what percentage of them have the skill's to do that on any
> platform/language combination.  Of them, who has the spare time and
> inclination to learn something totally different, if they don't "need
> to"...  I suspect a small fraction of 0.1%  Good on them though, go roll
> with it...

Dave, this is a good and valid point.  Someone with the right knowledge and 
background needs to do this work right.  My point is that if one person would do 
this one time, then everyone could use it everywhere Java runs with the utilized 
platform (J2SE vs J2ME for example has some different capabilities to consider).

> As to Java's IO control, well, it's already been said.  Sun's dropping
> of native java support for COM port, at about the time of the rise of
> USB strangely is a pain.  Utilities like RXTX work, but again, there
> seem to be several versions skulking about, and not all the new ones
> work with newer Java app's.  Then you're back in the usual mess, of how
> to get right down to the metal as it were, across multiple platforms, so
> you can never have true cross platform portability if you are going to
> use external IO.

I understand that this seems bad.  But, the point is, that the javax.comm API 
design is a fixed thing.  You can code to it, and have portability to all 
implementations of that API.  Sun chose to make that an optional API rather than 
an included API.  Not sure why, but that's what happened way back when.  So, the 
developer just needs to find the appropriate implementation to ship with their 
application for everyone to use.  The SUN version can be shipped with 
applications.  All of them have native code libraries that need to be installed 
correctly etc.  That's a little more labor for the developer to work into their 
installation task, but not insurmountable.

> As others have said, the main problem for the users, is getting it all
> installed up and running, citing LimeWire as a good example of how it
> should be done (regardless of what I think of the app itself, and some
> of it's users!)  It is certainly a "hands off" approach, and sorts out
> what it needs, and goes and does it.   Sadly, much ham (and an awful lot
> of commercial stuff sadly) does not do that.

Yep, many people doing software development in the HAM community don't have 
enough training or information, or motivation to get it right.  That's a real 
problem for many people.  Some argue that HAMs ought to be smart enough to 
figure it out.  I think it's important to not waste unneeded time in peoples 
lives just because you can.

> The majority of the so ham so called SDR stuff currently about, is
> computer controlled analogue RF/IF, down to for example 12kHz, then
> soundcard DSP.  That is not true SDR.   Go look at what Amsat among
> others are doing in respect of true SDR.   I doubt much will be done in
> Java, but I could be wrong.  It would certainly be a good way to go for
> the User Interface part, but I doubt for the embedded code.

The realtime aspects of audio capturing that are possible with the PC sound 
cards, in conjuncting with buffering built into the audio subsystems at the 
kernel level (because these are time sharing systems), allows a non-realtime 
system to be used to do this audio processing.  The visible effect is a delay in 
audio caused by the computational time of the audio processing pipeline.  As I 
mentioned before, this is already visible in our cellphones.  We're learning to 
talk slower and respond with less interjection :-)

Doing the audio processing in Java vs C vs C++ vs ASM code is only going to 
result in a different latency (audio delay) between the arrival of the audio and 
its output to the speakers for your perception (hearing).

The issue is, once it's done in Java, it can be more widely used than if done in 
C or C++ or ASM targeted at a specific OS, library or processor type.

> It's not beyond imagination, to have one box that could do just about
> everything.  PSK31, WJST, CW, APRS as well as "normal" voice comm's, all
> running together on the same hardware.  Transmitting on one HF band,
> while doing that Receiving on another though, is still as much a
> challenge as it always was, but numerically not impossible.  I guess the
> closest we have to that at the moment, on VHF at least is DSTAR, but at
> a cost.

Yep, that's what I'm trying to make apparent.  With a little bit of focused 
effort, HAM radio could be in charge of the next generation of RF, instead of 
all of us sitting around waiting for the manufacturers to decide what we need. 
Building new, high class digital equipment with hardware is expensive and time 
consuming.  Doing it with software means that a lot more people can take up 
where others leave off and further explore concepts without everyone having to 
build some basic hardware to get to the starting point.

> I'm sure Java will improve over time, but it has a way long way to go
> yet, for true "all hardware platform" portability that some may claim it
> has now..

I think it's all a matter of perception.  There's a lot of FUD going around from 
8 year old experiences.  Java has come a long way from those early days. It 
really can perform quite adequately.  I used it for repeater recording, echolink 
VOIP GSM codecs (http://javecho.dev.java.net), enterprise class data processing 
(30+ database transactions/second) and a wealth of other things related to 
satellite communications etc.

Again, I'm really interested in hearing about peoples bad experiences and trying 
to understand where all of the negativity comes from.

Gregg Wonderly