Re: [Tlf-devel] Fw: WARC bands

[Ervin Hegedüs - HA2OS]

Hello,

On Thu, Jan 23, 2014 at 08:18:56AM -0600, Nate Bargmann wrote:
> 
> Here is a hare-brained idea from the peanut gallery.  ;-)
> 
> 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.
> 
> 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.  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?

Thougths?

Doh'...

you stole my idea... :):)

I thougth about these things what you described, and I got the
same result: this isn't a convient solution, to rewrite the code
for an unkown contest.

However: there are _not_ too much contest type, and not too much
unique rule - TRLog supports about 60 different contest, I think
we can catch up that :), but I don't think that's our goal...


What I thought:
- "programmable" moduls in different ascpects, eg.:
  - GUI
  - logic
  - external resources, like multi list, ...
- the "language" could be a markup language (*), or an enbedded
  script language (**)


Ok, I think I carried away... - I'm sorry :)


* I think the XML is terrible, and unusable; JSON is a readble,
but it's strange for most people; but YAML could be very good
choice
** may be that's sounds crazy, but there is a _very_good_
application firewall, called "Zorp"[1]. That's written in fully C,
but uses an internal Python interpreter. If you write the
firewall rules, you write a Python script, whit all advantages of
Python.

[1] http://en.wikipedia.org/wiki/Zorp_firewall


73,

Ervin
HA2OS

-- 
I � UTF-8