Guten tag Markus,
I love this idea. I, too, have been thinking about how we should take
computer integration to a higher plateu, but you have obviously put some
REAL actions behind your thoughts. You are on the right track.
I'm not sure I totally agree with attempting OS independence. As an old
Unix bigot myself, I'd like to see this, but I wonder if the pain is worth
the gain. Like it or not (I don't), Microsoft has a stranglehold on the
OS market. Had the Unix vendors not bickered throughout the late 80's and
early 90's, NT may not have come to fruition.
By no means, am I knocking the existing computer-based tools we use. Some
brilliant people have done wonders for our activities by supplying us
with inexpensive (sometimes free) and revolutionary software and hardware.
I personally thank those people for their contributions. It's healthy
for the hobby if we pursue forward looking concepts. I also think many
of these same people will be key players in future developments. I sure
hope so.
The time has come for distributed computing concepts to move outside the
bounds of the corporate and academic worlds. I know this is a bold and
scary proposition for many of us, but it's called progress. There was once
a time when hams were the people who pushed the envelope of technology.
In many ways, those days are as dead as DOS, but Markus demonstrates that
there is still a glimmer of innovation left in our ranks. I know we
CONTESTers have the talent to nurture and cultivate this seed that Markus
has planted. I just hope those talented individuals have the time.
A full discussion of this topic may be outside the scope of this reflector,
but I would like to participate in some discussions on the topic. Maybe
some of the talented people I refer to above could join. I don't consider
myself to be that talented, but I am genuinely interested in the subject.
Besides, any idiot has a good idea occasionally. I suspect this idiot can
add a little to the QRM. :-) If the masses agree, and someone is willing to
establish a side-bar discussion, please include "gdo@lucent.com" on the list.
Time constraints will likely prevent me from contributing more than words.
Besides, I'm sure others can write much better code than I can. It's been
a long time since I've done any serious software development. I now spend most
of my time talking to people and writing architecture documents.
Clearly, the pioneers of this environment would be serious multi-multi
efforts and adventurous single-ops. Cost and complexity would certainly be
an issue, at least in the beginning. Few stations could absorb such
overhead until the technology matures.
I'll try to add some momentum to Markus's ideas by putting some fertilizer
on his seeds (interpret the metaphor as you see fit, HI!). I've included
some comments to the original posting below.
Vy 73 de Glenn O'Donnell, K3PP
"My comments and opinions are purely my own. They do not necessarily
reflect those of my employer, family or friends, although they should." :-)
> From: owner-cq-contest@contesting.com (Markus Hammelmann)
> Orig-From: Markus Hammelmann <markus@wg104a.wh.uni-stuttgart.de>
>
> Hello fellow contesters,
>
> the last discussion on the advantages and disadvantages of DOS/Windows/UNIX
> based computers for contest logging made me want to tell you about an
> idea that I have in my mind for a little while now:
>
> I am thinking of an (nearly) OS independant solution for contest logging.
> It also includes ditrubuted computing and Client / Server based ideas.
>
> I know that this is a big effort to realize it and so I would like
> comments on the following ideas.
>
>
>
> 1. The database:
> The idea is to set up a client / server database server. Using ODBC/JDBC
> makes it independent from the front end, makes it easy to backup and easy
> to access for multi/multi stations.
K3PP: Bravo! Implementing "REAL" database systems can solve some of the
record locking and data integrity problems we sometimes see with
current "networked" operations. It also enables a concept I once
touched on regarding instant results submissions and compilation.
Looking even further, it can be possible to keep tabs on other stations
DURING the actual contest!
> 2. The "look and feel"
> Using Tcl/Tk or Java (I am not that interested in Java, but just an idea)
> would make it easy to set up different OS architectures.
K3PP: I'm no expert on the pros and cons of either, but everyone seems to be
jumping on the Java bandwagon (even Microsoft!). Market inertia may
may push this decision towards Java. It also solves many of the OS
independence issues by virtue of its design.
> 3. The templates
> I like the idea of NA's templates. But this template editor is not that
> suitable, especially for european contests. But I know that is very hard
> to code something that is adequate for all opportunities.
K3PP: Ditto here but I think the "template for all needs" is not really
that difficult. I believe some enhancements to NA's method can
work. Of course, I'm not as familiar with the European concerns
so I could be speaking from a naive point of view.
> 4. Use of existing data
> Possibility to use the CT MASTER.DTA file fo example. By the way, does
> anyone has any info on this special data format?
K3PP: Absolutely! Some existing standard data formats and files appear to
be more than adequate for the future. As the old saying goes, "If it
ain't broke, don't fix it!" Let's improve the existing systems, not
totally replace them for the sake of something new.
> Pros:
> - Possibilty to bring the database server outside the RF "polluted" area
> - Easy access to all data especially for Multi/Multi Setups
> - Easy handling of the network (at least for experienced guys) not this
> serial
> port daisy chain solutions
> - Easy database backups, not nessesarly done be the ops (Masterconsole)
K3PP: I haven't yet tried the K1TTT Ethernet driver for CT networking, but
I like the concept and I hear it's quite good. For the future, we
should use the OS's native network code. Again, we don't want to
re-invent the wheel if we can adapt those wheels to a new chassis.
Again, I'll add to the list of pros:
- Extensible over the Internet to go outside the walls of the
station. The possibilities are huge. With the future access
technologies like DSL (1.5 Megabits), this will be easier
as time goes on.
> Cons:
> - Not that easy to set up for a casual computer user
> - CW sending cannot be realized OS and hardware independant
> - You need computers with a good performance
K3PP: Number three will take care of itself. We still use a lot of 386/486
computers, but you almost can't buy a brand-new slow computer anymore.
As people replace their old "klunkers", the new stuff will be more
than enough. It's almost become a social disgrace to own the slowest
computer on the block. Of course, hardware and software will always be
leapfrogging each other. It's a fact of technology that we can't avoid.
> As I mentioned above, this is just an an idea and of course there are many
> things that won't be too easy to realize and perhaps I am totally wrong,
> but anyway, I would like you to mail me (to the reflector board) any comments.
>
>
> Best 73 / 55 de Markus DL5OBZ / K2XS
>
> http://wg104a.wh.uni-stuttgart.de/markus/hamradio.html
> e-mail: markus@wg104a.wh.uni-stuttgart.de
--
CQ-Contest on WWW: http://www.contesting.com/_cq-contest/
Administrative requests: cq-contest-REQUEST@contesting.com
|