Subj : Re: Suggestions: Area Ind
To : G00R00
From : WKITTY42
Date : Thu Jan 31 2019 07:20 pm
On 09/17/14, g00r00 said the following...
g0> wk> there is that, too... but should mystic allow for an address to be
g0> wk> entered more than once to start with? ;)
g0>
g0> Why not? If the Sysop thinks that they need to create 10 address
g0> entries with the same address then whos to say they should be denied of
g0> their dreams?!?! ;)
:LOL:
g0> wk> i don't see a problem at all with areas being listed in more than one
g0> wk> group if they are actually configured to be in more than one group...
g0> wk> seems to me to be expected otherwise the area would be listed in only
g0> wk> one group, right? ;)
g0>
g0> It can get a bit messy this way. If someone has 450 bases, 10 are
g0> local, 440 are networked and they are split across 3 networks. They have
g0> the following groups:
i've been thinking about this for several days now and the first thing that i
see is the blurring of the line between tosser message groups and bbs message
groups... they are not the same thing and they really shouldn't be... tosser
message groups are for limiting access to other systems linked to the message
areas... bbs message groups are for limiting access to individual users on the
local system...
IIRC, the index reader is based on the functionality of golded which is an
external to the bbs sysop reader... like most other external sysop readers,
they generally use the tosser's message group definitions and don't know
anything about the bbs' message group definitions...
i agree with your assessment about the problems of areas being in multiple
groups but that's with them being in multiple bbs message groups... areas in
the tosser are only ever in one tosser message group and i don't know of any
tossers that allow an area to be in more than one group...
with that said, i would base the index reader on the tosser's message groups
(not addresses!) kinda like you have now but i would separate the tosser's
message groups from the bbs' message groups... additionally, linked systems can
be a member of several of the tosser's message groups so that they will have
access to only those areas they are allowed... there may also be a need to have
read and write levels for linked systems as a system may be placed on read-only
status for a message area... basically the linked systems in the tosser are
like the users in the bbs... each has similar options as far as groups they
can access and read/write premissions but that's as far as it goes...
consider that many operators just import or set up their areas with some sort
of "backbone" areas file (eg: backbone.na)... those areas are all the ones
carried on that distribution system but there's no distinction made in that
list for (eg:) sysop only areas... in the tosser, this distinction is not
needed because systems should be able to link to those areas... in the bbs,
however, users may not be allowed to even read certain sysop only areas and in
many cases, they aren't allowed to write in them...
we see the same thing when it comes to "backbone" distributed regional and
zonal areas... folks in other regions or zones may not be allowed access to
read and/or write in those areas... in this case, the tosser groups may be
used to split them from the general areas while both are pulled/fed to the
same upstream distribution system(s)... in the bbs, the groups may be similar
or not but defining the segregation in the bbs on a user level is more
detailed...
files areas are in the same prediciment, too... file tosser groups are not
the same as bbs files areas groups... there are zonal, regional and network
level file areas as well as private ones that only certain systems can even
know about... on the bbs level, users may or may not be allowed access...
individual area definitions would likely end up with a second group
definition field... the first being used as now with the security format (ACS)
and the second being for the tosser group the areas belong in... so i guess
one might consider a secondary system based ACS but i don't know...
FWIW: every time my FE or ALLFIX add new areas to my main BBS system, i have
to go look them over and ensure that i get the permissions set properly for
them for other systems' access as well as my bbs users' access... i gotta
find my flags fields definitions sheet again, too... that's how i was limiting
access to some areas in my RA...
eg: security 25, no flags set - general user
security 25, A1 - visiting sysop
security 25, A2 - Z1 user
security 25, A1,A2 - visiting Z1 sysop
security 25, A1,A2,A3 - visiting Z1R18 sysop
security 25, A1,A2,A3,A4 - visiting Z1R18N3634 sysop
so to read a general sysop area, the user would have to have flag A1 turned on.
to read a Z1-Only area open to all Z1 folks, flag A2 has to be on. to read a
Z1-Only Sysops-Only area flags A1 and A2 have to both be on. yeah, it can get
pretty deep and demented awfully damned quick without a cheatsheet... security
levels alone are not sufficient expecially when one has visiting sysops from
other regions, zones and even networks... i used to try to use security levels
for that but couldn't... the flags help and the combination is somewhat
easier but there can still be holes left...
RA has four sets of flags.... each with 8 bits... A1-A8, B1-B8, C1-C8 and D1-D8
and even they may not be enough in some cases but RA does also allow for a area
definition's access to require that a flag is off... i haven't even tried to
start figuring out how to use the flags offered by mystic and systems like
synchronet which seem to have only 26 flags with several of those being
pre-dedicated to certain tasks or options (eg: QWK network account)...
anyway, sorry for the rambling in the FWIW section... the main parts of this
message are before that and i hope i got them written decently enough to
express the problem as i see it and a possible solution...
