filearea 1
acs normal
desc BBS Doors
download m:\base\filebase\lcl\bbs\doors\dailey\doors
upload m:\base\filebase\uploads
end filearea
...
...
...
; end .lcl.bbs.dailey
filedivisionend
; end .lcl.bbs
filedivisionend
You can nest as deep as you want, and file areas can represent your physical
directory structure on disk which makes sorting and organising files more
natural.
Which ends up looking like this when they're displayed:
============================================================================
File Areas --------------
For more areas, type ".." to go up one level or "/" for top level
areas.
File area (Area, "["=Prior, "]"=Next, "?"=List):
============================================================================
And at the "File area (Area..." prompt users can enter atomic paths to switch
file or message areas eg.:
File area (Area, "["=Prior, "]"=Next, "?"=List): lcl.bbs.soft.opus.tools
instead of typing in meaningless numbers when displaying "groups & subgroups"
while switching areas etc.
To my knowledge the Synchronet & RA-style only allows a two-level breakdown of
file & message areas into groups & subgroups. That's crap. imo.
ml> MvanL> I'm not fully purposely descending into a BBS software war,
ml> me either... i'm just trying to figure out what you are
ml> trying to describe and respond to that...
[...]
ml> hunh?? nonono... i'm talking about joe sysop and john sysop who both
ml> download the same bbs software and install it without any modification
ml> using all the default screens and menus... users to
ml> their boards see the same presentation... now, one of
ml> those users calls fred sysop's bbs which is also
ml> running the exact same software but fred has taken the time to "skin it"
ml> by making his own screens... next door to fred, is alex
ml> who also runs the same bbs software... alex has gone
ml> even further because he has found the menu editor and
ml> come up with his own menu keys and option layouts...
ml> alex comes from an old mainframe style world where
ml> everything is chosen from menus of no more then ten
ml> (10) options... that makes it very easy cause there's
ml> only 0-9 to hit but it makes it more complicated
ml> because now there have to be dozens more menu screens...
ml> none of the above have "hacked" anything or had to work
ml> around any problems as there are none... now, the
ml> callers, on the other hand, may be a bit confused or
ml> maybe not...
Yeah. Well to draw distinctions between BBS software it's more comparable to
compare the standard features (excluding mods and plugins). That's the approach
I use, until people/authors start cheating by distributing plugins & modules as
part of thier "standard" package which is arguably misrepresenting practice to
me :)
ml> MvanL> For example it'd be a nightmare to mimmick the Maximus area
ml> MvanL> divisioning behaviour in Synchronet / RA where areas are
ml> MvanL> numerically defined instead of alphanumerically capable.
ml> but it isn't all that hard... one could easily do it with a script... but
When BBS functions/functionalities are not part of the BBS binary, or outside
the source code that's cheating.
ml> yes, alphanumeric access to an area may be easier for
ml> some... but it also all depends on what you get used
ml> to, too... i have to wonder, though, at what happens
ml> when things are moved around and reorganized... with RA, there are two
Well one day I'm going to add environment variables to Maximus control files
baby. Add a preprocessor to Silt that translates Operating System environment
variables and/or #define directives in Maximus Ctl files.
If I want to change or move things around, just change a global variable.
eg.
C:\> set bbsdrive=M:
Filereas.Ctl:
#define BASE \base\filebase
#define UPLOAD_DIR %%bbsdrive%%\BASE
filearea 1
acs normal
desc BBS Doors
download BASE\lcl\bbs\doors\dailey\doors
upload UPLOAD_DIR
end filearea
MuahaHAHA (evil laugh).
ml> numbers with each area... one used for display and the
ml> other used behind the scenes for the record number of
ml> the area definition as well as the datafile names... so
ml> i can "renumber" my areas without changing anything and external software
ml> won't loose track as long as they go by the proper id
ml> number... this type of thing also comes into play with
ml> offline mail setups... in the past, if a sysop added
ml> new areas by inserting them instead of appending them,
ml> users who downloaded offline mail before the change and
ml> uploaded after the change would inevitably get some
ml> messages posted to the wrong message areas thru no
ml> fault of their own... no fault, really, of the sysop,
ml> either... many folk like to see stuff alphabetically
ml> instead of in arrival order...
What you've described is the limitation of numerically based area definitions,
which necessitates use of an internal ID number to maintain consistency when
inserting new or reordering areas.
In Maximus any file or message area can be given a unique definition or label
so there're no clashes. They work like domain names, so the label/area itself
acts like a RA equivalent internal ID number. If I wanted to reorder an area I
just cut & paste a block definition somewhere else.
Should the need to increment "numbers" arises I'd have to resort to a sed/awk
script or something. <shrug>
But then again, Maximus can implement the TAG keyword for filearea definitions
since it already supports it for message areas. This would solve all
perceivable problems and allow external programs to differentiate between areas
that have the SAME number in the SAME "subgroup". Sort of how Squish and
areas.bbs works with universal static echoarea tags.
I'll add it to the todos list. Heh.
All this flexibility stems from Maximus' native support for alphanumeric area
definitions.
[...]
ml> apparently you don't have all the facts, either... bob
ml> jones is limited by a job contract in what he can do as
ml> far as developing and coding anything... the
ml> limitations of that contract are almost expired...
ml> until that expiration time passes, he felt that it was
ml> safer for the existing code to not be handled by
ml> himself so that it would not be misclassified and have
ml> that company he was contracted with trying to claim it
ml> for their own...
ml> MvanL> I remember that thread.
ml> it didn't seem that you did...
I don't lead-in my messages/replies with disclaimers and clauses. It's all
assumed knowledge unless there's blatant ignorance or misinformation has
occurred.
ml> MvanL> I appreciate all efforts and contributions towards Maximus.
ml> MvanL> That doesn't change the fact that there has been nothing new
ml> MvanL> since 2003,
ml> you can't blame bob for what happened to him WRT that
ml> job he took... truth is that most bbs software is a one
ml> man endevor and always has been... i'm aware of only
ml> two or three packages that were more than one person
ml> teams but every one of them started as a one person
ml> project... two of those are dead and gone and another
ml> has gone back to a one person endevor...
I'm dissing the lack of progress on Maximus. But I'm blaming noone.
There're about 5 people working on Synchronet.
I agree with Andrew Clarke's post about attitudes to OSS. Either pay someone to
do it or go DIY.
When VMware doesn't work anymore I'll have to pay a whole team to port it to
another platform using MVC++ or something. Who knows.
I might even contract Rob Swindell =P
--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)
