[DogParkList] Whirlwind (long)

[Don Agro]

Hi Scott,

On 8-Jan-09, at 6:25 PM, B. Scott Andersen wrote:


> 3. The current Cab-converter input is ADIF. I'm not sure if that  

> will be the best choice after Don's rewrite. Instead, it might be  

> better to simply access the relational database Don is using as a  

> backing store for the log. I suspect the log will have columns  

> similar to those identified as "fields" in the ADIF specification-- 

> but Don can also break out individual items if that makes  sense. In  

> short--some of the goofy things we've had to do to capture contest  

> exchange data in the SRX and STX text fields may be better handled  

> with the New-and-Improved MLDX and its database. If so, this will  

> make Cab-converter that much better and contest submissions that  

> much more robust. This is something that Don and I should work out  

> at some point.


Yup - it is plain vanilla SQLite and can be read directly. It is very  
powerful, scaleable and I am very pleased with the way it is working  
out. I will send you  sample .sql file when you are ready, but we may  
be adding more fields as I read ahead :)


> As a side-effect of this, MacLoggerDX may also be able to achieve  

> data interchange via ADIF with other contesting programs because our  

> data layout will more closely mimic that used by those other  

> programs. For example, the SRX_STRING is the only way we can  

> currently capture TEXT fields. Yet, the ADIF specification has the  

> following:

>

> CHECK - Contest check for ARRL sweepstakes

> CLASS - for Field Day

> CNTY - The contacted station's secondary administrative division


Already in MLDX ADIF Export.


> COUNTRY - obvious

> GRIDSQUARE - for VHF contests and Stew Perry, for example



> IOTA - Islands on the Air identifier for the contacted station


Already in MLDX ADIF Expor.


> ITUZ - ITU Zone of contacted station for CQ WW, etc.

> PRECEDENCE - for ARRL SWEEPS

> TEN_TEN - 10 10 number


In MacLoggerDX for Cocoa ADIF Export.

All good suggestions Scott, thanks.


> Right now we cram all this stuff into the SRX field as each contest  

> demands. The ARRL CHECK string is particularly urksome. It would be  

> REALLY nice to sort this stuff out so it went into individual  

> columns and was captured at QSO time with some sensible and  

> streamlined UI. Don is asking for our help on these things.  

> Providing _meaningful_ help will be very hard work indeed! And,  

> given the scarcity of resources on both Don's end and mine there are  

> no guarantees that anything proposed will be implemented. Don takes  

> a chance every time he spends a few days or a few weeks working on a  

> particular thing or another that the effort will fall short, not  

> gain acceptance, be ignored, or not help his bottom line. He's  

> brave. We'll need to be just as brave working hard "on spec" (prior  

> to any commitment) organizing our thoughts if we wish for them to be  

> considered and perhaps implemented.


Sounds like a sensible approach. Adding a carefully thought out list  
of data inputs, corresponding database fields and ADIF outputs is not  
a huge task - picking the right ones and presenting them usefully is :)

The Contest panel belongs to the contesters. Within reason, I will put  
there whatever makes sense to the majority of contesters.


> 4. I believe that there are two categories of feature requests  

> contesters might

> push for:

>

> (*) Data entry and management during the contest

> (*) Data import, export, and processing post-contest

>

> The first group consists of database column definitions, data entry  

> screen designs, and contest-specific logic.

>

> The second group consists of import/export to LoTW, eQSL, and other  

> services, possibly the export of logs or log segments to HTML so  

> that they may be published to the web, and robust interchange  

> between MLDX and Windows-based programs through ADIF and its  

> continually evolving standard. This second group of feature requests  

> have a broad appeal outside of the contesting community and would  

> help all MLDX users, not just the contesters.


I agree completely.


> Because the contesting part of the MLDX community is also some of  

> the more heavy users, we should be expected to apply our extra  

> expertise and insight into helping with the non-contesting-specific  

> features as well.

>

> LONG MESSAGE. SORRY.

>

> I typed too long. Sorry. These are my thoughts except for one: Don  

> has done an excellent job supporting the Macintosh community. There  

> are other logging programs out there--even for the Macintosh--yet we  

> don't flood these other vendors email boxes with ideas and demands.  

> We continue to go back to Don because he continues to deliver. Thank  

> you, Don, for your efforts. They are appreciated.


Thank you Scott.

73 Don Agro VE3VRW