Subj : Re: Suggestions: Area Ind
To : G00R00
From : WKITTY42
Date : Thu Jan 31 2019 07:20 pm
On 09/16/14, g00r00 said the following...
g0> Av> It didn't..
g0>
g0> Av> Sep 16 21:12:29 DEBUG R BSY Secure AKA 3:770/1@fidonet busy
g0>
g0> So BINKD is reporting a BUSY address if the AKA is on the line twice?
[spock] logically speaking, it seems to be correct... [/spock]
g0> This doesn't seem right to me. I (or someone) should probably ask them
g0> if this is intentional behavor.
sounds like a plan ;)
g0> I should be able to filter it, so that so Mystic only sends the address
g0> once.
there is that, too... but should mystic allow for an address to be entered
more than once to start with? ;)
g0> Av> Gotta say it seems a bit strange to have to announce to the world via
g0> Av> bink sessions an address that is bogus just so I can sort a bunch of
g0> Av> message bases to display nicely in the index reader.
g0>
g0> You shouldn't have to. I wonder if this is a BINKD bug?
seems to be more related to having to use system addresses multiple times to
group message (and file??) areas for the index reader... it seems to be
another plus point to altering the grouping code to use mystic groups instead
of addresses...
consider if one wants to group all bbs areas together and they are pulled
from different networks... then there's maybe grouping all FTN related areas
(bbs, tossers, mailers, etc) together and having them coming from different
networks...
g0> Av> Do you think would could just get the reader to allow bases to be
g0> Av> displayed by message groups or something similar?
g0>
g0> Probably not. We'll see.
here's my vote to do so...
g0> Groups in Mystic are not static they are calculated dynamically. One
right but there's still the base group number that never changes... couldn't
that be used as it is in other programs?
g0> base often has many group memberships. Most people also use a global
g0> group, some use a "local" vs "networked" group, etc. If I were to try
g0> to sort by a "group" it'd give odd results (many bases would be in the
g0> list more than once). This makes it sloppy, confusing, and difficult to
g0> synchronize data between the duplicate entries.
i don't see a problem at all with areas being listed in more than one group
if they are actually configured to be in more than one group... it seems to
me to be expected otherwise the area would be listed in only one group,
right? ;)
maybe the above will help in figuring out what to do to handle this problem...
