HIding Areas {03}

On Monday 23 June 2003 11:47, Ingo Brueckl wrote:

>  BS> The problem here (and I suspect with Sean's system as well), is that
> the BS> BBS is carrying the complete echomail backbone (well over 400
> message BS> areas), however there's only a few that I actually follow.
>
> I see.

That's good, because I wasn't sure that my explanation was very clear.

>  BS> In BBBS, each user is allowed to "subscribe" to selected message
> areas, BS> and only those areas are scanned for new mail and such. It would
> be BS> great if BlueMail would either read and honor this "subscription"
> BS> information from BBBS,
>
> blueMail does this for all services ... but mail files/databases like the
> BBBS Message Base (and Hudson Message Base as well). The idea behind this
> is that while reading a mail file or database, you get full access to the
> whole file/database - no restrictions apply. For BBBS, in specific, you get
> the sysop configuration, who should probably be subscribed to all areas.

That's interesting, because as sysop of my BBBS system I have "access" to all 
areas, but am only "subscribed" to a few.  All of the ones that I have 
"access" to appear in the list, whether or not I'm actually "subscribed".  
Does this sound like I'm missing something in the way I'm using BlueMail, 
because from your description, it sounds like I should be able to get the 
filtered (subscribed) list now.

>  BS> or (preferred because it is more generic and can be universally
> applied) BS> allow a separate list of the areas which should be displayed.
> Any areas BS> not on the subscription list would not appear in the list of
> areas (or BS> be processed in any way via BlueMail).
>
> I'll see whether this can be done. (For a more generic solution, there
> should be area filter file possible for every "system", i.e. every mail
> something blueMail can open, so the area filter files (.aff ?) should be
> named like bbbs.aff, hudson.aff, soup.aff, and probably be stored either in
> the INF or a separate directory, or the INF file itself.)

The more generic the better.  On my previous programming projects, nothing 
bothered me more than having the same program take divergent paths simply 
because of the operating platform.  That makes upgrading and code maintenance 
so much more difficult.

> And, you probably only want these .aff to be applied while reading, not
> when using the reply manager, don't you? (Which may be confusing.)

I hadn't thought about that.  My first thoughts are that it wouldn't bother me 
if they were also filtered out from the reply manager.  My reasoning being 
that it wouldn't make sense for me to enter a message into an area that I 
don't read.

> I think, it'd best (not for me, but the user) if this could be controlled
> from within blueMail, for example with a tri-state "long/short/custom" area
> list...

Whatever you think is best.  I can live with it either way.  Shucks, I even 
appreciate it as it is now.  I was just expressing a "wish list" idea.

>  BS> (unless I "bastardize" the message area titles on the BBS to provide
>  BS> some unique filtering criteria just for this purpose).
>
> Nobody should do this.

Thanks for seeing that.  It's been my experience that a lot of developers 
wouldn't.

> >> I already though about adding a few input box macros (\0 ... \9).
>
>  BS> I usually forget about using the defined macros and retype all the
> stuff BS> each time.
>
> Maybe \0 should bring up a list of the definitions of \1 ... \9 for
> selection? (No idea at the moment whether this easily can be done...)

Any way would be fine.  I was just meaning that I always end up forgetting 
about the macro functions, regardless of what program I'm running.  I think 
it's just one of those senility things...  <grin>

Thanks again.

Bob

--bluemail-----------------------------------------------------------
Post to the list by email to [email protected]
To unsubscribe email [email protected]
--POWERED BY MDAEMON!------------------------------------------------