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 _______________________________________________ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
