[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Tlf-devel] Quo Vadis tlf... (long)
[Tlf-devel] Quo Vadis tlf... (long)
Tue, 06 Jul 2004 18:04:01 +0200
Quo Vadis tlf...
It has been 2 years since I started tlf and I have put a lot of time and
energy into the project while having great fun along the way. From a simple
logging/keyer program for the WPX contest, tlf has evolved into a complex
system with multi-node networking, cw keying, voice keyer, contest recorder,
support for a plethora of different transceivers, and support for quite a lot
of contests. There was never a master plan for tlf. And like every complex
system which grows organically, there are numerous loose ends left to be
tied, and the possibilities for enhancement have no limits. Time to sit back
and think about planning the scarce resources (mainly myself up to now).
In order to secure the future support for tlf some choices have to be made.
One choice is entirely mine; i.e. which percentage of my time i want to spend
on tlf (the competition includes sailing, operating PA0R, contesting,
dxpeditioning, travelling, the family, and enjoying life in general. Yeah
right, not Work. My productive hours are not limited by work anymore but by
The other choice can be influenced by the tlf user community, viz. to set the
priorities for enhancing the program... I will give you my own views about
it. If you see things in a different way, please speak up. Like in the real
world, the one who Speaketh The Loudest will have the Biggest Voice. Unless
you are in a democracy lead by a very strong Democrat...
Basic medium term goals and specs for tlf
1. Tlf is an open source Linux program
This means that I expect porting to other Operating Systems to be done by
others, whom I will support if necessary and within the framework of my
capabilities. It also means that you can change the program if you are not
happy with it.
2. Tlf is a Contest / Dxpedition logger, no general logging program for
award hunting etc. Of course tlf can be used as a front end to more
elaborate Linux logging programs like Xlog by using the ADIF export facility.
3. As I don't know anything about VHF/UHF contesting, I will concentrate my
efforts on HF. Of course I will support anyone who can take care of the VHF/
4. Main goal for tlf is to support, not slow down the contest operator. It is
optimized for high rates. Bells and whistles are secundary to speed. No
mouse. High readability. Secundary screen information is delayed on purpose.
If you think this is not necessary try to run 200 qso's/hr on a 33 MHz
5. Tlf must be a high quality, reliable program. This has priority over
flexibility (e.g. more contests). Bug fixes have a high priority, feature
requests a lower one.
6. Tlf must be able to cope with 100k+ qso's in a multi station dxpedition. At
the moment the limit is 10k for a contest log. As I want to use tlf on a
major dxpedition in April 2005 this is high on my priority list. All fixed
arrays have to be made flexible, to take away program limits on lists, logs
7. Although the band map feature is very usable as it is now, I plan a
8. Tlf must get a much higher level of documentation, even if it grinds the
programmer down to a halt. This will encourage outside support and enhance
Longer term plans for tlf
When we've done all of the above, the PROTOTYPE of tlf , version 1.0 will be
One of the problems of tlf is, that the author is a cw contester, not a
programmer. I had not written 1 line of C code before starting tlf. The
skills came with time. A perfect example of 'training on the job' (some call
it 'programming by errors'). Those of you who do a lot of programming
themselves will notice the difference in programming style between the latest
code and the first attempts from 2 years ago. In fact I should freeze the
development now and start a new modular design based on the working
prototype we have at the moment. I doubt, however, if I could motivate myself
again to undertake such a huge adventure. It would mean a stand-still of the
development of tlf for 1 ... 2 years.
Another way of tackling the problem is to take the code as it is now and
isolate / transform / modularize / clean / document it one piece at the time.
This would take even longer, but it would enable tlf to grow in the mean
time, be it at a slower pace than it has done during the first 2 years. There
is no better motivation than working against a deadline toward the next,
enhanced version if you want to use it in the next contest.
In the long run I want to turn tlf into a library to make it independent of
the user interface.
In my view there are some major issues regarding the acceptance of tlf by the
9. Guest operators 'do not care about what software to use as long as it is
CT'. The lesser experienced the OP, the more he needs CT. So try to 'sell'
the CTCOMPATIBILITY mode first.
10. Not enough effort is taken by the Linux community to make it look 'as easy
as...'. Hence the ICONS on the Dxpedition desktop. The more users, the
better the code.
11. Casual contesters will find tlf 'antiquated' compared to 'N1MM'. No
graphics, no mouse, no menus to click.... Not Window$. Don't try to convince
them. They are happy.
12. In fact, I don't care if someone wants to sell his soul and his wallet to
a multinational. But it becomes different during club events, fielddays,
multi-op efforts etc. You, as the sysadmin, will have to do some selling.....
13. The 'don't touch my window$ laptop' syndrom. An abundance of Linux laptops
is still science fiction. The DXpedition Disk live CD may help. I will put
some more time into it (updates etc...), as it seems to raise interest in
using Linux for logging, and it helps me organize my own dxpedition stuff.
14. References and success stories are missing. I am preparing a presentation
you could use at your local club meeting, contest club meeting etc... I have
been invited to do some presentations at the RRDXA contest club barbecue in
Germany, and demo's during the Dutch yearly ham meeting in October. (This
takes preparation time as well.... sigh... so I may as well put it on the web
Open projects I have no time for at the moment
15. Log analysis software. Not necessarily inside tlf, ADIF input would be
o.k. I think. I have a wish list available... (ncurses based pse...). Nice
project for Perl!!
16. Addition of some major contests: IARU, WAE etc... simple but time
17. Update of tlfdoc.html... The man file is up-to-date, but the html doc is
not. This is not difficult, but it's WORK.
18. Various HowTo's describing how to configure multi setups, voice keyers,
etc etc... from own experience.
The development speed of tlf depends to a great deal on outside support. Due
to personal circumstances my own development capacity has decreased by 50%,
and I hope to keep it at that level.
Meanwhile the testing time for a new feature has increased to 10 x coding
time. If you have any comments, or if you want to volunteer, please let your
Voice be Heard...
address@hidden or address@hidden
- [Tlf-devel] Quo Vadis tlf... (long),
Rein Couperus <=