| |
PA2AGA > HDDIG 19.12.99 15:37l 221 Lines 7474 Bytes #-9645 (0) @ EU
BID : HD_99_320D
Read: DL6KCF GUEST
Subj: HamDigitalDigest 99/320D
Path: DB0AAB<DB0PV<OE2XOM<OE5XBL<OE3XSR<OE3XBS<S50BOX<S50MBL<IV3AVQ<IW3EFI<
IW9EXL<SV1AAW<SV1AAW<EA7URC<PE1NMB<PI8HGL<PI8VNW
Sent: 991219/1026Z @:PI8VNW.#ZH2.NLD.EU #:35155 [HvHolland] FBB7.00g $:HD_99_32
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : HDDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA26277 ; Sun, 19 Dec 99 09:23:53 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.67/7.5.3) with SMTP
id AA00017267 ; Sat, 18 Dec 99 16:09:27 MET
Date: Sat, 18 Dec 99 15:42:38 MET
Message-Id: <hd_99_320D>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 99/320D
X-BBS-Msg-Type: B
> exactly work need to be defined super tightly, obviously -- you know.
>
>
>.
------------------------------
Date: Fri, 17 Dec 1999 06:46:32 -0800
From: "Dana H. Myers" <Dana.Myers@West.Sun.Com>
Subject: Kenwood Control program that runs on Liunx AND Windows!!!!!
Cathryn Mataga wrote:
>
> > I also am thinking about with the winter time coming to devise a
> > proposal for a common radio command protocol. This could be used by the
> > control program which talks to a server which translates to and from the
> > actual radio.
>
> Oh, yes, this is a good idea, in my humble opinion. Something like
> a libradio for Unix and a radio.dll for windows. Ideally something
> open source, maybe even BSD-licensed, so that Radio manufacturers
> could take this code, make a few changes and ship a driver with their
radios.
I believe there's a difference between a protocol specification (which
is what was proposed) and an API (which is what you're apparently
describing). A properly designed protocol is both designed and
specified in platform-neutral terms, and describes the exchange of
messages between agents. In the case of a remotely-controlled
radio, the server and the client may be on different systems,
in the case of a locally-controlled system, the server and the
client may be on the same host. Either way, the same functionality
could be available.
Once a protocol is defined, client libraries which provide APIs
would follow, as well as servers.
> Me, I'd prefer as thin a wrapper as possible, and as simple as
> an interface as is possible, probably with caps bits. In the API, though
> I think the issues such as what you call in what order, and how things
> exactly work need to be defined super tightly, obviously -- you know.
The real challenge to defining a general radio control protocol
(or API) is developing a syntax which adequately enumerates and
provides control and status for radio features. If done properly,
a general-purpose UI framework could be built, which configures
itself after enumerating radio features. Actual details of radio
control are handled at the server, perhaps through the use of
Java servlets.
Agreed, the protocol needs to address any sequence/state
issues, but I do not believe it is practical to expect all
clients to behave properly. So, it is important to understand
all major states of a radio and associated features and
provide an adequate set of exceptions to cope with ill-behaved
clients.
Keep in mind, a good remote radio control protocol probably
allows for the encapsulation of audio/video streams using
standard formats (mp3, GSM, wav, mpeg, etc.).
Dana K6JQ
dana.myers@sun.com
>.
------------------------------
Date: Fri, 17 Dec 1999 11:31:07 -0500
From: "Rob" <NoEmail@NoWay.com>
Subject: Kenwood Control program that runs on Liunx AND Windows!!!!!
Hi Jeff,
Thanks for info on TCL/TK.
Why did you choose to use TCl/TK over JAVA which seems to be more popular
and provide the same functionality (i.e. code that is portable over many
platforms)?
Rob
"Jeff Pierce" <piercej@preferred.com> wrote in message
news:38586F13.7DC40DC6@preferred.com...
> I have developed a graphical control program for the Kenwood
> TS-140/440/940 radios that runs under Windows, Linux and several other
> Unices with virtually no code changes.
>
> It runs under Tcl/Tk 8.2.2. For those not familiar with Tcl/Tk it is a
> scripting language (like Perl, Javacript, etc.). It's main feature is
> it's great GUI tool kit, the Tk part. It's really great feature is the
> same code can be run on Linux, Windows and several other Unix systems
> WITHOUT changing the any code. The screen shots on my web page are from
> both Linux and Windows95 with NO code changes. The only code that may
> need to be changed is to specify which serial port to use.
>
> If you do not have Tcl/Tk it is available for FREE from
> http://www.scriptics.com/products/tcltk/8.2.html
>
> It is a cinch to install on Windows and Linux. On Windows you just
> execute the .exe from the above source to run the install wizard. Then
> download kentcl.zip from my site, un-zip it and double click on it. For
> Linux, just follow the compile/installation instructions.
>
> --
> Jeff Pierce, wd4nmq
> piercej@preferred.com
> http://pages.preferred.com/~piercej
>
>
> -----------== Posted via Newsfeeds.Com, Uncensored Usenet News
==----------
> http://www.newsfeeds.com The Largest Usenet Servers in the World!
> ------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers
==-----
>.
------------------------------
Date: Fri, 17 Dec 1999 16:46:35 GMT
From: spamhater@ucesucks.nouce.com (Rich)
Subject: Kenwood Control program that runs on Liunx AND Windows!!!!!
On Fri, 17 Dec 1999 11:31:07 -0500, Rob <NoEmail@NoWay.com> wrote:
>Hi Jeff,
>
>Thanks for info on TCL/TK.
>
>Why did you choose to use TCl/TK over JAVA which seems to be more popular
>and provide the same functionality (i.e. code that is portable over many
>platforms)?
>
At this point in time, Java's portability and performance are still
way, way overrated. Heck, if you want true portability with
rich functionality across *many more* platforms than Java, you're
better off using Perl.
- Rich
>.
------------------------------
Date: Fri, 17 Dec 1999 12:21:23 -0500
From: Jeff Pierce <piercej@preferred.com>
Subject: Kenwood Control program that runs on Liunx AND Windows!!!!!
Exactly right Rich...
Plus the amount of resources needed to run Java are much more. Java was
not written for the web. It was produced by Sun, but had no market. The
web actually gave Java a home as a stop gap for multiple machine
running. In fact Java byte code is not a "new" idea. UCSD P-system
Pascal from the 70's was one of the, if not the, first to compile to
byte code. CPM, Apple, and TI Home, to name a few, computers all ran it.
Java just took that idea to a object oriented language. Which ofcourse
really bloats it.
In fact, Tcl/Tk is making great in-roads into cgi on the web. I think
there is even a Tk kit for perl. Remember Tcl is Tool Command Language
and is line oriented. It does all of the data handling, math, etc. Tk is
Tool Kit and is the tools for the Graphical User Interface, buttons and
such.
Rich wrote:
>
> On Fri, 17 Dec 1999 11:31:07 -0500, Rob <NoEmail@NoWay.com> wrote:
> >Hi Jeff,
> >
> >Thanks for info on TCL/TK.
> >
> >Why did you choose to use TCl/TK over JAVA which seems to be more popular
> >and provide the same functionality (i.e. code that is portable over many
> >platforms)?
> >
>
> At this point in time, Java's portability and performance are still
> way, way overrated. Heck, if you want true portability with
> rich functionality across *many more* platforms than Java, you're
> better off using Perl.
>
> - Rich
--
Jeff Pierce
piercej@preferred.com
http://pages.preferred.com/~piercej
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
To be continued in digest: hd_99_320E
Read previous mail | Read next mail
| |
