Hiya Bob,<br><br>The only thing out of that list we aren't doing is the unique ID of the source and the display to the user on whether the message was acked or not.  I'll work on that....<br><br>Mesages use decay, support both REPLY-ACKs and ACKs and will automatically ack any messages sent to a user while they are actively online on the site viewing the message interface.<br>
<br>Greg<br><br>NV6G<br>OpenAPRS.Net<br><br><div class="gmail_quote">On Wed, Oct 22, 2008 at 10:30 AM, Robert Bruninga <span dir="ltr"><<a href="mailto:bruninga@usna.edu">bruninga@usna.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> It should be noted that <a href="http://www.openaprs.net" target="_blank">www.openaprs.net</a><br>
> has had full messaging support for about<br>
> two months now.  Just signup for an account<br>
> (which is free)...<br>
<br>
Greg, this is great news.  I think it is very important to have<br>
that initial layer of authentication.  I have not used it yet,<br>
but here are some additional issues which maybe you have<br>
addressed:<br>
<br>
1) Messages should be transmitted using the original APRS decay<br>
algorithm to improve delivery reliability.  I'd suggest<br>
something like Now, then 15<br>
sec later, then 30, then 1 min, then 2, then 4 then 8 and then<br>
stop.<br>
<br>
2) Such a system should have a line number so that it is acked.<br>
And the application should watch out for the ACK.<br>
<br>
3) Such a system should display to the browser sender when it is<br>
acked or<br>
when it has timed out.  It could also display the retry counter<br>
and time-to -go, and time-to-die as an added bonus.<br>
<br>
4) Somewhere in the message packet, the source of the Message<br>
Engine should be identified.  There are two places.  One is for<br>
anything going into the APRS-IS could use some kind of ID syntax<br>
in the PATH like the Igates do now.  The other is in the<br>
LINE-NUMBER.  I suggest the last two bytes for a unique<br>
two-letter abreviation.  So the line number could be like this:<br>
...{xxxID where "ID" is the engine sending the message.<br>
<br>
Some radios only display the last two bytes of the line number<br>
so that is a great place to show how the message was originated.<br>
Of course, this obviates the use of REPLY ACKS, but that is a<br>
small price to pay for the identification we gain.<br>
<br>
Is there anything else we should require?<br>
<br>
Thanks<br>
Bob, Wb4APR<br>
<br>
</blockquote></div><br>