[Xastir-Dev] Messaging interface...]

[Mark - N2PGD]

Gerry,

> 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.

Personally, I disagree.  I think the popups, at least in their current
state, are nothing but an annoyance.  They always seem to get in the way
when I'm trying to do something else.  I end up sending a message and
then dragging the resulting window off to another virtual screen so it's
out of my way.  I wouldn't be against a small indicator saying you got a
new message or something, but I don't see the need for a big popup
window.

> 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.

"getting files from the TNC"???  The message interface for APRS does not
make use of the TNC bbs, is this what you are talking about?  I don't
see how the lidlist will help.  I was talking about the ability to sort
and filter the archived messages.

> 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.

Regardless of it's orginal intent, I do see APRS being useful for ECOM
situations.  We have successfully used APRS in many public service
events and it saves a lot of time to use the text messaging rather than
try to send the information over voice.  What I really believe an ECOM
situation needs is smart operators.  People who are aware of the
underlying technology, know its weaknesses and watch for those
weaknesses.  Given that, I think the simple message passing mechanism
works quite well.  I like Curt's idea of creating an enhanced messaging
mechanism even more.  I've never played with UI-View, so I don't know
what they do for message passing, Curt?

> 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.

This may be a real possibility.  The actual data size for most MTA is
pretty small.  All we would really need to do is mark an original packet
as mail and then spew out the MTA data.

> 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.

Your absolutely right here, the messages do need to get through.  I
don't think the UI frame method is any less reliable than many voice
nets I've monitored.  The advantage of a computer based ECOM structure
is that you have automatic message logging!  People have extremely
different approaches and abilities when it comes to keeping paper logs
during an ECOM event; even then, paper logs are lost, destroyed, etc.
It's extremely easy with computers to setup a simple backup mechanism,
even if it only means keeping a copy on a hardrive and floppy.

> 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.

No offense taken ;)  Likewise, with my rebuttal/comments I only intend
to encourage out of the box thinking.

73,

Mark