|
From: Bastien F. <f4...@cr...> - 2019-03-14 13:34:08
|
On 2019-03-14 14:19, F6BHK wrote: > You don't answer Jim's questioning. > > Besides, Bill gave you a quick view on UDP msg. And I cannot agree > more. > > UDP msg give us all what we need to know about WSJT insides. Why would > we need something else? > > 73 > > Serge > > > On 14/03/2019 12:19, Bastien F4EYQ wrote: >> On 2019-03-13 17:59, Jim Brown wrote: >>> On 3/13/2019 7:11 AM, Bastien F4EYQ wrote: >>>> I've develop a "Radio Cloud" for ham people, This cloud purpose a >>>> logbook "online" >>> >>> LOTW and eQSL work quite well. Why do we need another one? >>> >>> 73, Jim K9YC >>> >>> >>> _______________________________________________ >>> wsjt-devel mailing list >>> wsj...@li... >>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >> >> Hello Jim, >> >> A quote is always better than a bad answer : >> >> "We always have the choice. We are indeed the product of our choices." >> Joseph O'Connor >> >> >> 73 Bastien. >> >> >> _______________________________________________ >> wsjt-devel mailing list >> wsj...@li... >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel Hello Serge, It would have been much simpler for me if a real webservice client API exists or we can select the target server but if the software sends local UDP packets to transmit the QSOs (As Bill explain), I got in touch with it. I'm just going to have to develop here a small C # client for CRX that will send the reformed UDP packets to the CRX webservice via SOAP or JSON. The client will include the user configuration for the logbook webservice (user / password / ID of the target log to syncronized). For now I can not do otherwise, the CRX client will also be compatible with other heavy software broadcasts like HRD / LOGGER32 or N1MM. Basically I would have liked not to reinvent the wheel of this heavy client software (who do not agree on a unified QSO sharing protocol), but if it must be done, I will stick to it. Bastien. |