[Xastir-Dev] Messaging interface...]

Gerry Creager N5JXS gerry.creager at tamu.edu
Thu Jul 10 08:55:23 EDT 2003


If we're talking about real messaging, a pop-up isn't bad.  That said, 
I'd LOVE to be able to set the DND bit so I can deny the messages until 
I want to be messed with again.

I would LOVE to see a message status window, callable from a tab menu, 
which would allow me to scan who's sent them, and then select the ones I 
want to recall from the archive.

I like the idea of filtering, but if you're getting files from a TNC, 
you can always set the lidlist in it to block the bozo's.  Then again, 
being able to set that filter in the program would be a benefit, too.

Message threading will be hard, since what we have amounts to SMS for 
ham radio without the reliability.  No subject line.  Threading won't be 
easy or intuitive.

<RANT>
Despite what Bob Bruninga has postulated, APRS is not suitable for ECOM 
message handling.  It's a short message system designed and most 
appropriate for short status and keyboard chat operations.  If it's 
important enough to send as a real ECOM message, we need to revisit the 
mechanism.

If we need to be moving real messages across this system, we need to 
engender a real message system.  In my mind, and with the main thrust of 
this list originating from the *nix environs, this means sendmail or one 
of its (working) cousins.  So you send a message by means of an MTA and 
read it with a mail client.  Most of the grief of handling is taken care 
of for you, your users/customers are already familiar with e-mail, and 
printing and archiving are already considerations.

As Bob B. periodically reminds us, APRS was designed for tactical 
situational awareness.  Sometimes, when you try to enhance something too 
far, it stops working as you'd hoped.  We're using UI frames.  If we're 
gonna do messaging in an ECOM situation, the messages need to ge 
through.  They need _REAL_ acknowledgement.creating a UI ack mechanism 
on top of the APRS format for messaging is not a good solution.

</RANT>

Please note:  That rant is aimed at the idea of using a less than best 
effort messaging mechanism on what at best is a best effort radio 
network.  It's NOT aimed at Mark.

73, gerry

Mark - N2PGD wrote:
> Folks,
> 
> So now that the latest stable release is out, I'd like to start a
> dicussion/design thread on how we can make xastir's message interface
> better.  The only other APRS programs I've played with have been APRS-CE
> and WinAPRS.  Here are some suggestions I have, from my experience with
> those interfaces and personal wishlish items:
> 
> - Get ride of the message popups.  These always seem to come up at the
> most unfortunate times.
> 
> - Have all messages listed in one window.  Among things listed, include:
>  * current status (could be color coded or field with different
>    qualifiers).  Status could include:
>      - oustanding ack: still in the process of sending
>      - acked
>      - delayed: message retries have exceeded some retry limit after
>        which the message is marked delayed.  Xastir will try sending
>        the message again, if it sees packets from that station
>      - canceled
>      - reply: this message has been acked and is a reply to a
>        message you received
>  * list station you are sending the message two
>  * obviously, the message content
>  * list the number of retries/delayed/timeout
> 
> - Flexible filtering options:
>  * I like the distance filtering and would certainly keep it.  This is
>    something WinAPRS didn't have!
>  * I'd like to be able to filter out messages to/from all of my
>    stations.  We could just filter on the base callsign, i.e. N2PGD and
>    I would see messages to/from N2PGD, N2PGD-9, and N2PGD-15
>  * I'd like to be able to filter out messages to/from only this
>    particular station.  This would mean filterin on the station
>    callsign, i.e. N2PGD-9
>  * custom filtering where we allow the user to put in regexp for
>    filtering
> 
> - Message logging:  I'd be interested in having the ability to log three
> different kinds of messages:
>  * all messages
>  * messages to/from all my stations
>  * messages to/from only this particular station
> 
> - Viewing messages via thread:  I haven't come up with a completely
> success method for determining a message thread, perhaps a combination
> of time and station calls?  Even if it only grouped them by to/from
> callsign groups, that would be handy.
> 
> - Message printing:  This probably sounds like a crazy idea to some, but
> could be really handy in the case of ECOM.  It would be good to have
> them formatted in some nice way, with origination info, time, date, etc.
> I'd like to see a few different priting modes:
>  * The ability to highlight a single message and print it
>  * The ability to highlight a message thread and print it
>  * Every message gets sent to the printer
> 
> - NTS messaging.  WinAPRS presents the user with an NTS message window.
> It then takes this window, breaks it into various APRS messages and
> sends them off.  If WinAPRS receives such a group of messages, it
> recombines it into an NTS message format and presents it as an NTS
> message to the user.  Again, this would be really handy in an ECOM
> situation.
> 
> So what do people think, any of these good ideas?  I'm sure there are
> some more/better ideas out there.
> 
> Mark
> 
> 
> 
> _______________________________________________
> Xastir-dev mailing list
> Xastir-dev at xastir.org
> https://krypton.hscs.virginia.edu/mailman/listinfo/xastir-dev

-- 
Gerry Creager -- gerry.creager at tamu.edu
Network Engineering -- AATLT, Texas A&M University	
Cell: 979.229.5301 Office: 979.458.4020 FAX: 979.847.8578
Page: 979.228.0173
Office: 903A Eller Bldg, TAMU, College Station, TX 77843



More information about the Xastir-dev mailing list