[Tlf-devel] Quo Vadis tlf... (long)

[Rein Couperus]

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 
health problems.).
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         
e.g. 
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/
UHF stuff...

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 
machine.

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 
etc...

7. Although the band map feature is very usable as it is now, I plan a 
complete rewrite.

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 
maintainability.

Longer term plans for tlf
===============

When we've done all of the above, the PROTOTYPE of tlf , version 1.0 will be 
ready.
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. 

Issues...
=====
 
In my view there are some major issues regarding the acceptance of tlf by the 
contesting/dxpedition community.
 
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 
site). 

 
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 
consuming. 
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. 

Support welcome 
===========
 
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... 

73,
 
Rein PA0R

-- 
address@hidden or address@hidden
http://www.couperus.com
http://savannah.nongnu.org/projects/tlf