[aprssig] Centralised message server
Lynn W. Deffenbaugh (Mr) ldeffenb at homeside.toSat Nov 21 02:50:39 UTC 2009
- Previous message: [aprssig] Centralised message server
- Next message: [aprssig] Centralised message server
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Keith VE7GDH wrote: > Personally, I don't think it's a good idea for some server to hold > messages for later delivery. The sender should send the message and > get an ACK... or not. We all know that no ACK doesn't necessarily mean > the recipient didn't get the message, but an ACK does mean that they > definitely did. Clients like UI-View can send a message <n> times and > then "retry on heard" if necessary. If it's the original sender > sending or re-sending the message, it's them that's receiving the ACK. > I think it would add a layer of complication if they had to check > elsewhere to see if an ACK had been sent by the recipient. > Your preference is exactly the reason for the message from the server offering to buffer and retry (not everyone is running UI-View or keeps it online for "retry on heard" to work) as well as offering the 3rd option to never offer again to that station. I definitely wouldn't want a server delivering MY messages later unless I gave it permission to - on each and every occurrance. As for the "check elsewhere for the ack", that'd be a good addition to my proposed design. When a buffered message is finally delivered to (or denied by) the recipient, a positive acknowledge could be sent back to the originator (and automatically buffered) indicating that the message was (or was not) delivered along with a date/time stamp. Lynn (D) - KJ4ERJ
- Previous message: [aprssig] Centralised message server
- Next message: [aprssig] Centralised message server
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list
