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
wsjt-devel@lists.sourceforge.net
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
wsjt-devel@lists.sourceforge.net
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.
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
