One of the big advantages of XMPP (Jabber) as the underlying protocol is a rich set of services that depend only on the terrestrial servers for their implementation. And it's all there already, servers and clients both.
If somebody wanted to do it, an AX25 - XMPP gateway would be pretty simple to construct, purely as an adjunct to a terrestrial server implementation.
Similarly, if there were a need, it would be trivial to encapsulate APRS messages in XMPP. Not the other way around, however.
73 Frank AB2KT
Robert McGwier wrote:
John B. Stephensen wrote:
I hope that the U/V digital service is 8-bit transparent so that it can be used efficiently for non-text communication, like APRS and collecting weather data with the fewest number of bits. It's also not a store-and-forward system so it really isn't messaging - although that could
To keep the system stateless on the spacecraft since we do not want to add a coprocessor, increase the internal communications complexity etc. Frank proposes and I support him since I believe it is right that we will use jabber servers on the ground to hold the data AND do store/forward. I do not want to build a messaging file system,. etc. on the spacecraft. Cooperation servers on the ground, using the net to move data between them, seems to be the right way to go.
We particularly like the ejabber server. It is implemented in Erlang/OTP.
The conference went well. I am taking a couple of days off from AMSAT and spending them with Shann, N2HPE, touring. I will be home Wednesday.
Bob
be added if message size was restricted. The number of data rates implemented in the ACP or SDX could be increased, so attaching names to each data rate may be a problem. How about calling class 1 advanced low-speed satellite communication (ALSC) and class 2 and 3 advanced high-speed satellite communication (AHSC)? There could then be a suffix for each data rate, such as AHSC-4800 and AHSC-256K.
73,
John KD6OZH