Re: [Tlf-devel] Fw: WARC bands

[Thomas Beierlein]

Hi Nate and others,


Am Thu, 23 Jan 2014 08:18:56 -0600
schrieb Nate Bargmann <address@hidden>:

> * On 2014 22 Jan 23:56 -0600, Thomas Beierlein wrote:
> > The whole initialization code is very complex and not easily to
> > change. It is on my todo list already but changign needs a lot of
> > care. Maybe we should write it completely from scratch.
> 
> Here is a hare-brained idea from the peanut gallery.  ;-)

While I was talking about scoring and contest handling in my mail, you
are quite right. It would be good to write a completely new tlf.
Question is have we time and man power to do it? Anyway - I am in for
it. 

> 
> If (and I say "if") a rewrite of some sort is desirable, then it may
> be desirable to separate certain parts of TLF into a library so that
> core functions such as duping, country lookup, scoring, managing the
> log file, etc. would be separate from the UI.  Then other UIs could be
> written to take advantage of the library so that a TR compatible UI
> would share the same core as one written for CT users or a general
> logger, for example.  As I see it, every logger out there does mostly
> the same things and each one reinvents all of these similar functions.
> The real differences are the UI and, up until such a libary would
> exist, varying degrees of completeness of the common parts.
> 
Right, one of the main things to do is to decouple the UI code from the
rest. At the moment it is scattered all around. A second thing to do is
to switch input handling to an event driven scheme - no polling of keys
anymore. Reason is that most graphical UIs would require such a scheme
anyway. Both is on the to-do list.

Your other ideas to have a 'generic' logging machine with components
for holding qso data, scoring lists and rules, writing cabrillo and
so on is a very good and tempting one. And you are right that would
allow to concentrate the efforts between different logging programs. I
believe that idea was proposed already on the list some time ago. The
main work is to define what should go into that library and how to
structure it. But it seems worth to be done.

> No matter the UI, a callsign given to the country lookup routine would
> return the same answer based on the cty.dat installed.  Log file
> format would be separate from the UI.  Perhaps mutliple log format
> backends could be incorporated as some users may prefer a flat file
> and others an SQL DB and so on. 

At the moment I would favor a tab separated list for the log format
with a header line documenting the order and contents of the columns.
That can be easily parsed, extended and even read and written without a
special program. It can also be handled with any scripting language
without problems.

> A common interface would allow
> easily reading a log file generated from one UI in another UI.  Each
> UI would have access to consistent Cabrillo and ADIF export and
> import.  A C library can be used with just about any other language
> so these core routines wouldn't limit UIs to be written in C.
> 
> Thoughts?

Besides the above comments one major step forward would be an unified
handling of the mass of contest rules around. Ervin did already wrote
about that in his answer to your mail. I would like to add a little bit
here:

If we look over to other contest programs we see that most of them have
the different contests hard coded and can simply choose which one to
use. Easy for the user - hard for maintenance (it requires a lot of man
power for development). N1MM seems to be an exception - he has a
contest rule generator for simple cases. 

Tlf tried another way: Some hard coded contests and some configuration
keywords to roll your own rule file. At present the chosen keywords
normally solve only special problems. It is not easy to know which one
to use without looking into the code and often we miss a keyword and
hurry to add just anther special one (Sounds familiar?)

As I see it the following could be a good way:

- Have some very general keywords to roll your own simple contest. The
  MY_COUNTRY/MY_CONTINENT_/DX_ POINTS may be a good idea for point
  scoring.
- Have some simple general configurable rules for multiplier counting:
  What to look at (call, exchange,...), what qualifies as a multi, once
  per band or once per contest,
  e.g. COUNTRY, DXCC, PER_BAND or CALL, PREFIX, PER_CONTEST
- Allow more than one rule and allow to specify how to combine them,
  e.g. DXCC and WPX-PREFIX added

- What can not be done these simple way (different points per band,
  special station bonus points, .......) have to be hard coded. These
  should be doable by the normal ham without a knowledge of the inner
  working of the program and without a need to compile code for the
  program.

  As Ervin told there are two ways. I too would prefer the second one -
  using a scripting language for that and I too think python is the way
  to go. It is easy to learn and program, the scripts can be debugged
  and tested independent of tlf and can be easily integrated into tlf.
  (I even did some thinking if we can not write the whole program in
  python...)

73, de Tom

> 
> 73, de Nate >>
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--