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
