That's why regression testing is so important. Carey, WB4HXE On Sat, Dec 5, 2020 at 11:24 AM Alan Groups <[email protected]> wrote:
> A prime concern with all software is development time, but in my > experience that's dwarfed by maintenance time requirements as that usually > grows at a faster rate than the development time as an app gets bigger. > > For example something changes in the core application, the plugin enabling > code (behind the public API) is unintentionally affected somehow, and > suddenly plugins (or worse only some of them) break. Cue loads of hassle > and work to find the bug(s), find the solution and release. Of course the > solution may then also unintentionally break something else; then round and > round it goes... > > Bill has said the facility to enable this suggestion to happen is already > present, so if there's sufficient demand no doubt someone will pick it up? > > Alan G0TLK > > 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"? > > 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? > > 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. > > Thank you for your consideration. > > -- > Dave Slotter, W3DJS <https://www.qrz.com/db/W3DJS> > > > 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 > [email protected]https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > _______________________________________________ > wsjt-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- Carey Fisher [email protected]
_______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
