On 14/10/2015 03:54, Martin Ewing wrote: > Thanks Bill and Alain. Hi Martin, > > I am making some headway using these leads. But I note that > NetworkMessage.hpp gives info for "Schema Version 1", but the data I'm > getting gives a version number of 2. Is there a major difference? The documentation in NetworkMessage.hpp is consistent with schema 2 at the moment, the reference in the commentary to schema 1 is incorrect.
The schema number is more related to the underlying field encodings rather than the arrangement and meaning of the message fields. Having said that, if a change to an existing message other than a trivial extension by appending new fields was needed then that would also require a schema number increment. The intention is that existing messages would only be augmented by adding new fields at the end so the later should not be needed. The corollary of that is that applications reading messages should not treat extra unexpected fields on the end of messages as an error condition. I am currently implementing a schema negotiation protocol so that servers can interact with clients running different schema numbers and vice versa, this protocol will be backwards compatible with the current protocol. I will check this in soon to the development branch. > > 73 Martin AA6E 73 Bill G4WJS. > > On 10/13/2015 05:11 AM, Bill Somerville wrote: >> On 13/10/2015 03:33, Martin Ewing wrote: >>> Hello all, >> Hi Martin, >>> I have some Python code that would like to communicate with wsjt-x. I >>> assume the UDP channel might be the way. Is there a concise >>> description/spec somewhere for what info gets passed back and forth >>> through UDP? >> The message protocol is documented in the following file: >> >> https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/branches/wsjtx/NetworkMessage.hpp >> >> >> in the commentary at the top. >> >> There is a reference application shipped with WSJT-X v1.5.0 called >> message_aggregator, this GUI application implements the server side of >> the protocol (WSJT-X is a client of the protocol). The following sources >> implement the client and server side plumbing: >> >> https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/branches/wsjtx/MessageClient.hpp >> >> https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/branches/wsjtx/MessageServer.hpp >> >> https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/branches/wsjtx/MessageClient.cpp >> >> https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/branches/wsjtx/MessageClient.cpp >> >> >> The are implemented using C++ and the Qt framework. MessageServer may be >> re-used by a third party Qt C++ application that wishes to get up and >> running quickly, we currently do not publish an executable library >> containing this as so far all implementers have been using other >> languages and have had to home brew their own protocol handlers. To help >> with those using Object Pascal I have made available a very basic >> message protocol handling unit which can be found here: >> >> https://dl.dropboxusercontent.com/u/4192709/message_aggregator.zip >> >> it uses the Indy Object Pascal library for basic Internet utilities and >> frameworks. >>> Thanks for any guidance. >>> >>> 73 >>> Martin >>> AA6E >> 73 >> Bill >> G4WJS. ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
