[aprssig] APRS Virtual Bulletin Board

[Robert Bruninga]

> Ok, it's obvious that you haven't seen the new 
> Messages / Bulletins /View feature on APRSISCE/32.  
> I did read your concept, and did implement
> it, as has Hessu before me...

Wow, great!

> but check out http://aprs.fi/bulletin/
> 
> I've gone one step further...  Since there's not 
> only a "line" number but also a "group" within 
> the BLN destination spec, I sort the bulletin 
> board based on source callsign, group, and within 
> group by line number.  

Now this is really neat and going someplace!

> see a screen capture of APRSIS32 bulletin view at
> http://ldeffenb.dnsalias.net.nyud.net/Tracking/Bulletins.png

> You mention "clearing" a bulleting.  How is that done?  
> Transmitting the bulletin group/line with no text?

When I wrote that, I wasn't sure either.  But yes, that should
do it because  the new blank line should overwrite what was
there before.  But then that blank line now is "recent" and will
not be eventually removed from the page because it now looks
new.  So I guess there was no formal process.  Maybe, in your
over-write old-lines algorithm, you can consider a blank line as
"old"... Or at least older than its most recent transmission
would imply...

> You also mention that the display is "SORTED 
> By callsign AND line number" but in the same 
> paragraph you say "The new line with the same 
> bulletin number REPLACES the previous 
> one."  I assume that should be the "same bulletin 
> number from the same callsign"?

Yes.  That is what I meant.

> My goal is to implement APRS as it needs to be 
> for the functionality that users can find useful.  
> Bulletins definitely fit that definition in
> my book, so I really appreciate the feedback 
> and assistance at helping me get it right.

Looks like a fantastic approach!

> PS. Given that many of us DO restart our APRS 
> clients periodically, I still believe persisting 
> the bulletins is a good idea.   Otherwise, when
> the client first starts, not only will the 
> "Bulletin board ... soon fill with all currently 
> ... bulletins", but the arrival of each of those
> bulletins will also be (quite inappropriately, 
> IMHO) alerted to the user as NEW.

But it assures that the bulletin page will only fill with
currenlty active info.  I was worried that if you brought up all
old bulletins at each restart, that bulletins would just go on
for ever and not disappear.  This solves the DELETE issue,
because at each restart, then the bulletin board begins blank...

> This is like crying wolf with the new bulletin 
> notification,...

Its your call.  I like the way APRSdos (after a restart) begins
to beep as the bulletin page is re-filled.  It gives me a warm
fuzzy that there are currently active bulletins out there, and
that the bulletins I am looking at on that page are not
something hanging on forever due to reboots...

But I can see your side too.

Bob, Wb4APR

> Robert Bruninga wrote:
> >> I also needed to persist the bulletins
> >> to avoid calling every received bulletin "new"
> >> when first turning on the software.
> >>
> >
> > I would not do it that way.  When one fires up his APRS on
RF,
> > his 40 line virtual Bulletin board should soon fill with all
> > currently relevant local RF bulletins.
> >
> > Almost every implementation of Bulletins in APRS follow-on
> > clones does it wrong.
> >
> > APRS Bulletins are NOT JUST ANOTHER MESSAGE line... To be
saved
> > in time sequence in a never ending history file.
> >
> > APRS bulletins are ONE LINE of a 40 LINE VIRTUAL BULLETIN
BOARD
> > that is supposed to be seen by ALL participants.  Its like
> > having a bulletin board at the EOC where people post
important
> > things for ALL to see.  They remove them when they are no
longer
> > active, they ADD them when new info becomes available.  When
one
> > needs updating, it is REPLACED.  When new lines are needed,
they
> > are INSERTED.  When there is no more room, the oldest are
thrown
> > away.
> >
> > Also each time a new one comes in, it is SORTED By callsign
AND
> > line number so that the sender can maintain a multi-line
> > bULLETIN topic by only updating the line that changes.  The
new
> > line with the same bulletin number REPLACES the previous
one.
> >
> > This way, there is never any question that everyone is
seeing
> > exactly the same VIRTUAL bulletin information everywhere in
the
> > event, irregardless of when it was initiall posted, or where
it
> > might have sat in time sequence.
> >
> > So, if a client just logs bulletins into a historical log,
then
> > it missed the point.  This was the number one issue I had
with
> > WinAPRS from day one.  It just logged bulletins into a
> > sequential bulletin log and so users were not seeing the big
> > picture nor could the Virtual Bulletin board be maintained.
> > Then other clones copied that, and the value of the Virtual
> > Bulletin board in APRS has very little value to those users
> > today.
> >
> > So, I hope you can implement the original concept.
> > Please see http://www.aprs.org/txt/bulletinBoard.txt
> >
> >
> > Though it is a challenge when watching the fire-hose on the
> > APRS-IS.  So I would make it RF ONLY, or some other way to
limit
> > its range to a LOCAL area.  If you could do that on the
APRS-IS,
> > that would really be neat!
> >
> > You could simply designate a BULLETIN LOCATION, and only
display
> > the VIRTUAL bulletin board for that location by only posting
> > bulletins originated within X miles of that location.  As a
> > default, I'd choose say 64 miles?
> > Thanks
> > Bob, WB4APR
> >
> >
> >
> >> If you view telemetry with my new client, it will use the
> >> most recently
> >> received definitions.  It will also mark the definitions as
> >>
> > used
> >
> >> whenever telemetry is received or new definitions are
> >>
> > received.  I'm
> >
> >> still trying to determine a good default for inactivity
> >> before dropping
> >> a non-referenced set of definitions and/or bulletins.  And
> >>
> > even when I
> >
> >> do that, it'll be some relatively long period after
starting
> >>
> > the app
> >
> >> before the purge happens so that the first activation after
a
> >>
> > 6 week
> >
> >> vacation doesn't wipe everything out unnecessarily.
> >>
> >> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile
and
> >>
> > Win32
> >
> >>
> >> ------------------------------------
> >>
> >> Yahoo! Groups Links
> >>
> >> <*> To visit your group on the web, go to:
> >>     http://groups.yahoo.com/group/tinytrak4/
> >>
> >> <*> Your email settings:
> >>     Individual Email | Traditional
> >>
> >> <*> To change settings online go to:
> >>     http://groups.yahoo.com/group/tinytrak4/join
> >>     (Yahoo! ID required)
> >>
> >> <*> To change settings via email:
> >>     tinytrak4-digest at yahoogroups.com
> >>     tinytrak4-fullfeatured at yahoogroups.com
> >>
> >> <*> To unsubscribe from this group, send an email to:
> >>     tinytrak4-unsubscribe at yahoogroups.com
> >>
> >> <*> Your use of Yahoo! Groups is subject to:
> >>     http://docs.yahoo.com/info/terms/
> >>
> >>
> >>
> >
> >
> > _______________________________________________
> > aprssig mailing list
> > aprssig at tapr.org
> > https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
> >
> >
> 
>