<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">I glanced through the specification and
have a few questions:<br>
<br>
1) How are filters handled? I tapped into the sample feed and
that's WAY more data than I'd like to have streaming to my mobile
phone.<br>
<br>
2) How can a client know if a legacy aprs1 packet has been Base-64
encoded or if it just happens to contain only Base-64 characters?
I didn't see anything in the specification (end of page) to
indicate the encoding?<br>
<br>
3) Is there a separate discussion group for this proposal? Or are
we supposed to spam the APRS groups with our comments ending up
with different discussion threads in multiple groups?<br>
<br>
And one comment: VERBOSE! In the case of paid mobile data plans
and 1200 baud RF channels, more (or even standards-based) is not
always better.<br>
<br>
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and
Win32<br>
<br>
PS. Not all of us like adopting 3rd party code over which we have
no control so making statements like "using one of the many
available XMPP libraries" doesn't do much for us.<br>
<br>
On 4/1/2017 3:32 AM, Georg Lukas wrote:<br>
</div>
<blockquote cite="mid:20170401073249.navqqnwp4n7h5ahm@boerde.de"
type="cite">
<pre wrap="">Hi all,
in the past I've often realized that APRS-IS does not work well with
mobile TCP/IP - latency on 2G or 3G causes delays that skew the position
reports; interruptions in the data connection are almost impossible to
detect at application level, and thus cause packet drops, etc.
On the other hand, with my other project (yaxim, a mobile client for the
Extensible Messaging and Presence Protocol / XMPP), all of these
problems have been solved years ago. Now I have come to the conclusion
that APRS and XMPP have many things in common:
- They are both network protocols to send real-time GPS and message
packets.
- They are mainly parsed by computers and displayed in a processed form.
- Both have a vast network of distributed servers to distribute data.
- For both, there are sophisticated web interfaces available.
- etc.
Therefore, I decided to bring together the best of both worlds and
created X-APRS: a revival of APRS based on the XMPP protocol.
You can find the protocol specification with color-coded examples here:
<a class="moz-txt-link-freetext" href="https://aprsdroid.org/xaprs/">https://aprsdroid.org/xaprs/</a>
Starting with the upcoming version 1.4, APRSdroid will only support
X-APRS over TCP/IP and HamNet, and legacy ARPS will be slowly phased
out.
However, this should not be a problem, as the new protocol will also be
supported by aprs2net and aprs.fi (expect separate announcements soon).
Client and server developers are encouraged to jump in and implement the
protocol, using one of the many available XMPP libraries.
You can have a peek at the data stream by issuing one of the following
commands:
telnet xaprs.aprsdroid.org 20482
telnet 44.139.11.254 20482
73 from Germany,
Georg DO1GL
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
aprssig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@tapr.org">aprssig@tapr.org</a>
<a class="moz-txt-link-freetext" href="http://www.tapr.org/mailman/listinfo/aprssig">http://www.tapr.org/mailman/listinfo/aprssig</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>