132Re: Replacement for Heavyweather.
- Aug 2, 2005see below
--- In firstname.lastname@example.org, "David Higgins"
> As I said, my skills are limited and C/C++ is not a strength.[snip]
> Writing the file once a minute isn't really the problem is it?[snip]
> -----Original Message-----
> From: email@example.com
> Sent: Tuesday, 2 August 2005 11:17 PM
> To: firstname.lastname@example.org
> Subject: [wuhu_software_group] Re: Replacement for Heavyweather.
> Unfortunately WUHU is currently only able to collect the
> weather data from the station via HeavyWeather output.
>Some ideas for consideration.
> --- In email@example.com, "David Higgins"
> <higginsdj@b...> wrote:
>> I have very limited programming skills (I can program in MS VB) [snip]
>> --- In firstname.lastname@example.org, "wuhu_software"
>> <wuhu_software@y...> wrote:
>>> I am interested in writing a replacement for Heavyweather
Openess, multiplatform support good.
Closed software and software developed for one platform ... bad, that
is part of the existing problem.
Reliance on HeavyWeather, developing MS VB code, etc. thus have
disadvantages. Using Java instead of VB for a top layer would be
better, but WUHU already does that. Use VB for bottom layer? That's
really not good.
The existing Open 2300 stuff (http://open2300.sourceforge.net/) is
multiplatform and being developed in an open environment, and if I
understand the literature there, reads directly from the base station
(read: not dependent on La Crosse HeavyWx sw). That seems like one
good option for a good base to build on. Is this off topic for this
WUHU seems to be great product, given its dependence on the HeavyWx
base. But we could do better. I'd say discussing pros and cons of
alternatives to WUHU is on topic.
A software better model might be ... Read directly from hardware with
well designed open software designed for the task (something like Open
2300, but wouldn't have to be that) to act as a software foundation
(base). Build modular cross platform components that use and build
upon that base. Java would be good for the applications. There are
various existing products out there that could be easily utilized as
components (reused) for the application(s). For example, various
graphing products exist that could be adapted, elminating need to
develop that functionality.
Openess facilitates troubleshooting and feature changes. Modularity
makes codes reuse easier. Choosing both openess and modularity should
maximize the number of possible developers. It certainly would draw
much interest of analysts, developers, users, and software
distributions (Fedora, etc.).
You know, if any of these Wx station HW companies (not just La Crosse)
were to be completely open with their interface specs and were to
actively cooperate with and support an open software development
effort, it seems their products would soon emerge as frontrunners in
product popularity (read "competative advantage"). They could protect
their hardware IP while supporting open software development. Win-win
for all. Company gains recognition and brand awarenes for their
support for open software development. Company builds market share
and profits. Users benefit from much better software and ability to
We wouldn't be complaining about about our inability to overcome 1
minute data increments. We'd already have implemented the fix ourselves.
- << Previous post in topic Next post in topic >>