Hi Dave This seems like an ideal thing to implement on top of the existing UDP interface, which Bill alluded to. You could have your app listen for QSO Logged messages from WSJT-X, do your QRZ lookup, popping a dialogue if necessary, then write the record out to an ADIF file owned by your app. Am I missing something?
Cheers Tom On Sat, 5 Dec 2020 at 22:51, Dave Slotter, W3DJS <[email protected]> wrote: > Hi Bill, > > You've been very clear in two separate messages that you're not going to > be accepting any code merges from me for this functionality -- even in a > suggested reduced format. This leaves me with two options (which are not > exclusive from each other): > > a) Relegate my work to a forked version of WSJT-X -- and one such author > has already offered to collaborate with me. > > b) Write a standalone program (probably in Python) to monitor for > additions to the wsjtx_log.adi file and then modify *just the log file > additions* "in-line" and hope that WSJT-X and my program don't have > contention issues over the log file. As you wrote previously, "WSJT-X > keeps its main logged QSO information in an ADIF format file. There's > nothing to stop users replacing that file with one augmented with QSOs in > other modes," -- it sounds like you're saying that WSJT-X is designed to > allow other third party applications from modifying the log file while > WSJT-X is running and the user is adding new log entries. If I > misunderstood this, please advise. > > 73, > > -- > Dave Slotter, W3DJS <https://www.qrz.com/db/W3DJS> > > > On Sat, Dec 5, 2020 at 11:05 AM Bill Somerville <[email protected]> > wrote: > >> Hi Dave, >> >> comments in line below. >> >> On 05/12/2020 15:37, Dave Slotter, W3DJS wrote: >> >> Hi Bill, >> >> Thank you for such a detailed and thoughtful response. >> >> Understood that QRZ XML API is a paid service. And yes, there are free >> services like HamQTH.com XML API. >> >> Three questions come to mind: >> >> a) What do you mean by "We also allow users to substitute an augmented >> ADIF log file"? >> >> WSJT-X keeps its main logged QSO information in an ADIF format file. >> There's nothing to stop users replacing that file with one augmented with >> QSOs in other modes, e.g. they might be interested in working new DXCC >> Entities that they have not worked in any other mode. WSJT-X even offers a >> push-button that causes the ADIF log file to be rescanned, to populate the >> in-memory indexes of worked before information, without having to pause >> normal WSJT-X operation. >> >> >> b) I re-familiarized myself with the User Guide, section 11. Logging and >> did not see an answer to this question: To what purpose is an empty name >> field provided in the WSJT-X Logging dialog? >> >> The Name field on the Log QSO dialog it there for the user to insert >> information that may be gathered at the time of the QSO, similarly the >> propagation mode was recently added. The Name field value, if present, >> populates the NAME field of the ADIF QSO record. That same information is >> published via the WSJT-X UDP Message Protocol "QSO Logged"(5) message and >> in the "Logged ADIF"(12) message. By this means interoperating station >> logging applications, or bridge applications to them, can pick up the >> entered information. >> >> >> c) Understanding that you are concerned with (among other things) feature >> creep in the core application, would you be willing for a compromise here? >> Rather than add that functionality into the main application, would you be >> open to an implementation of a plugin interface to allow third-party >> developers to add optional functionality for inserting the name field? That >> way you do not have feature creep in the main application, and users can >> decide for themselves whether or not to enhance their experience with >> WSJT-X. >> >> Currently WSJT-X has no use for a QSO partner name field in its ADIF log >> file, even though it has the capability to enter that field when logging a >> QSO, as I explain above. I assume you envisage WSJT-X scanning previous >> logged QSOs to redisplay the last name recorded, if any, in the log QSO >> dialog, or perhaps elsewhere in the UI during QSOs, or even against decoded >> messages. Each of those options requires a greater degree of processing and >> data management, but I don't see any real gain for users when the vast >> majority of QSOs made with WSJT-X do not exchange such niceties as an >> operator name. >> >> It seems to me that an application could be developed to subscribe to the >> WSJT-X UDP Message Protocol and augment Logged QSO messages along the lines >> you suggest. Such an application could then itself offer a service of >> augmented logged QSO records. Such an application need not have any >> interaction with WSJT-X other than subscribing to the UDP datagrams that >> are already available. Note that this is something that JTAlert and >> probably other station logging applications already do. >> >> >> Thank you for your consideration. >> >> -- >> Dave Slotter, W3DJS <https://www.qrz.com/db/W3DJS> >> >> 73 >> Bill >> G4WJS. >> >> >> On Sat, Dec 5, 2020 at 8:24 AM Bill Somerville <[email protected]> >> wrote: >> >>> On 03/12/2020 14:25, Dave Slotter, W3DJS wrote: >>> >>> Bill and Joe: >>> >>> If I were to develop an integration with QRZ to automatically look up >>> the full names of people associated with a callsign that's getting logged >>> and populate the name field in the log window, would you be receptive to >>> receiving and incorporating said patch? >>> >>> Please advise, and thank you. >>> >>> -- >>> Dave Slotter, W3DJS <https://www.qrz.com/db/W3DJS> >>> >>> Hi Dave, >>> >>> thanks for offering to develop such a facility, but personally I feel >>> this is out of scope for WSJT-X. In general WSJT-X is a *source* of >>> information gathered on the air, up to and including logging QSOs. There >>> are data feeds consumed by WSJT-X, but not many and none with any real-time >>> demand. We optionally take a list of known users of the ARRL LoTW service >>> so that decodes of CQ calls from users can be highlighted. This is >>> considered by many to to be valuable information when selecting who to work >>> because it may reflect the likelihood of getting a QSO confirmed for award >>> purposes. We also allow users to substitute an augmented ADIF log file, >>> perhaps from a main station logging application, that also allows WSJT-X to >>> highlight potentially more valuable QSO partners with respect to the user's >>> DXing goals. Adding further data feeds, particularly when the information >>> acquired is available from many sources and hence subject to ambiguity, is >>> not a high priority. Furthermore once these sort of more arbitrary >>> information inputs are considered as worth implementing, then there are >>> many more that might have perceived equal or greater merit to some user >>> subsets. That could lead to WSJT-X mission creep into the domain of main >>> station logging applications, which to a greater or lesser extent already >>> do these functions well as part of their core capabilities. >>> >>> I note also that the QRZ.COM XML data feed is not a free service and >>> therefore may not be required by many users who do not think this sort of >>> information is worth the price. There will surely be others that request >>> the same information from free to use sources like the Hamcall service, or >>> perhaps from one of the variety of paid call-book services that they may >>> already be subscribing to. The scope of such a facility will quickly grow >>> far beyond what you propose, with an associated ongoing maintenance and >>> support burden that may detract from the core purpose of a weak signal >>> communications tool. >>> >>> 73 >>> Bill >>> G4WJS. >>> >> >> _______________________________________________ >> wsjt-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >> > _______________________________________________ > wsjt-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wsjt-devel >
_______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
