
BAJA PROGRAMMING



          * Symbolist's Sysop Journal, 1 December 1994 *

                 __True "Rooms" for Synchronet__
                                or
            "How I go schizo from 10 p.m. 'til 2 a.m.
             (and we're both still fine, thank you.)"

                            **********

I worked for a long time to find a way to have discrete "rooms" or
"forums" on my Synchronet BBS, COMM*Net. In general, I like the form of
Compuserve's forums in that I can go into a topic-driven area and find
*everything* on that topic. And while BBSes in general allow this in
separate message areas and file areas, etc..., as a new user I found
this cumbersome and confusing. Plus, in my view, an online environment
needs to approximate understandable models for as broad a user-mind
base as needed. So - I wanted rooms.

Now, I know that many sysops and some power users won't like rooms. They
like speed and know how to get it out of the boards they use. However,
this "room" concept is priceless for many uses, plus, I'm stubborn and
used to think that I have a quick learning curve, and getting "rooms"
was stuck in my head (most of you know *that* feeling). I had to solve
it.

I am not a programmer, which will be abundantly obvious to any better
skilled person than I, and I'm sure many others could have (and may
now) seen this as a silly, easy problem. But there sure are a lot of
sysops (a couple are successful programmers too) who haven't done it,
and I was getting nowhere asking for help. So I plugged ahead...

[It's easy to spot me in a crowd. I'm the one with the brick-patterned
imprint on my forehead.]

                             -------------

                             Rooms Defined

        I define a room as a BBS area that can have every capability of
        the BBS itself, but may also have very limited capabilities;
        message areas, file areas, chat, text files, bulletins, and
        any doors or other external services I want.

        This doesn't sound too unique except that none of the room
        contents can be visible or scan-able from outside the room in
        the main board, and vice-versa. That means it is isolated
        totally and users in the room can do a new_scan_all and NOT have
        the rest of the board scanned too. And, users outside the room
        can't see or access any of the room's functions.

        Plus, to be the best modification, it needs to be integral to
        SBBS and not have the lags and clumsiness I associate with
        doors and some other external applications I've seen.


                     The Benefits I Want From Rooms

        1. If I want to run a totally separate BBS for a certain
        function, user group, or whatever, I want to do that from INSIDE
        my existing command shell, without running separate instances of
        some other BBS as a door. It should be able to have EVERY SBBS
        function within itself without interacting with the MAIN board.

          That means that users can go into the Real Estate Online room
          and have message groups, file Libraries, chat channels, text
          files, doors, and anything else that they want and won't get
          any place else on the board. The Real Estate Club (or
          whatever) can meet in privacy, even have membership access,
          configured in baja.

        2. The rooms can be either public or private.

        3. A room may only have a message base, or file area, or door,
        and not need the full BBS shell to function.

        4. It should have it's on ascii/ansi/rip "Welcome to the
        blah-blah club", and "Thank You for Visiting the blah-blah
        Clubhouse, come again soon!" login and logout screens.

        5. It should have its own unique menus and be able to function
        completely differently than the BBS if that's what I want.

        6. It should not stop offline reader users from their QWK
        functions.


        7. Hopefully requires nothing but integral SBBS functions to set
        up so that adding, and wrecking-balling any room is easy and
        involves no custom programming or software author support. No
        offense to the many excellent and responsive software developers
        out there (Rob and many others), but I usually need to talk to
        you at 1:30 a.m. - and I know you're working then and have no
        use for me!


                              --------------

                    Early Thinking & Other Problems
         (Of course my Early Thinking was PART of the problem!)


        I spoke with several sysops about this many months ago and everybody
seemed to want it too. Each had different views about what to use "rooms"
for, and none seemed to have a total solution.

        I logged on to boards where the sysop claimed on DOVE-Net to have
"virtual" BBSes and separate rooms or "matrix" logons and found the
identical problem in every case: while they had set up separate areas
with some menu/baja function to take users to the appropriate message
base or file area, or other function, when a user scanned_all for his
messages or new ones, he ended up scanning the entire board. I even saw
one sysop on DOVE-Net, many months ago, talk about running a separate
instance of Synchronet or some other freeware bbs, either as an external
program door, or as a baja function. That seemed very inappropriate to me too.

        It is clear that none of the sysops (or myself) wanted that, and
that we all wanted functionally separate rooms, or truly separate "virtual"
BBSes or more limited rooms.

        I spoke with Digital Dynamics about it and Rob said on one
occasion "Yes, you can do that now" and I hung up and didn't press for
the solution. (I'm used to that brick wall imprint after all.)

        Quickly I realized that in order to do it inside the current
shell, there had to be a way to isolate the functions and limit them to
the room only, without disrupting the rest of the board outside the
room. Both areas, inside the room and the areas outside, have to exclude
each other.

        It dawned on me that if I could toggle ARS flags from baja then
I could probably do this. However, baja doesn't allow this - although it
does allow other user toggles. So, to be sure, I spoke with Allen at DD
(who is also the Domain Entertainment developer), and he said "Nope,
can't toggle flags from baja at this time."

        It's one of those problems that you end up just staring at,
knowing that there IS a solution and you just can't *see* it. This went
on for several months while I set up and learned all the other "languages"
(read that "programs") needed to run my board. (A process still continuing
and that has me in "total immersion" - man, I pray to everybody's gods
for software documentation that doesn't assume I know *their*
assumptions!)

        What made it more frustrating was that I had successfully,
and easily, written a baja command shell adding instant online help
(without modifying or simplifying the menus - I hate novice shells - and
separated the Main and Message menus, and some other things. (Unlike
some other successful Synchronet boards, I'm ending up with only one
command shell that is getting modified beyond recognition and I'm not
going to take the time to modify all the other shells.)

        I had even contacted an SBBS sysop who is a skilled and bright
programmer and he said yes, he could write a utility with command line
parameters that could do what I wanted. It wouldn't take him long,
etc... and, we were working out how to pay for it, share it, etc...

                            +++++++++++++++

          *** And then, late one cold, coffee-tanked night...

there it was. Right in front of me. On page 261 of my Synchronet manual.
The MODUSER.DAT file. The drop file external programs return to the BBS
to alter user ARS settings! Could I use this? How? When does SBBS read
the file? I knew that from UEDIT, when I change a users settings, they
take effect immediately so I concluded if I could change them from baja
they must be similarly instant. [BTW, I learned long ago that reading
instructions and manuals is just part of living, so I read Synchronet's
manual constantly. "RTFM!" isn't lost on me. But, for me, I use a
different acronym - "RTFM&UI!" - "Read The Friggin Manual & Understand
It!"]

        I called Allen again (I think he knows my voice at the first
"Hello" at this point), and he said SBBS reads this file only on
returning from an external program that must be configured in
SCFG -> External Programs. <whew!> I was a step closer.

        In the last few months I've developed an email relationship with
the author of the book "Dr. Batch File's Ultimate Collection", Ronny
Richardson [ Windcrest/McGraw-Hill, a great book IMHO ], and have learned,
and done, some amazing (to me) things from DOS batch files, so I realized
that I could create a batch file as an external program to deal with the
moduser.dat placement.

        That's the key, but it takes several other modifications for it
to work. And in retrospect, it seems so simple that I can only laugh at

myself now (and thank some gods I can still laugh at these types of
problems!).

                              ------------

        I'm also sure that any first year programming student is ROTFL at
all this. But having solved it is a big win for me, and possibly for all
those sysops that have thought about but not pursued it. Or for those
that, like me, couldn't see past the mental trees blocking the forest!

        My solution may not actually be the most elegant or efficient,
but it runs fast and smooth, is transparent to users (with no
perceptible lags), and totally handles my original problems and needs.
After you understand it, it's simple and easy to arrange. I hope it's
helpful to you too.

        I have so much mental and physical energy (late nights, caffeine
overload, shouting at my wife and kids, and more) that I tried to think
of a way to compile this and sell it. Frankly, I'm sure others could
have figured that out and this would be uploaded to Vertrauen and you'd
be sending in your $10-$20 check right now.

        However, I've gained so much from everybody on DOVE-Net that I
haven't got the heartlessness to do that. (My wife says that's my main
life-problem, not enough greed.) Plus, it seems almost fraud. After all,
99.9% of it is just making a slightly obscure modification to Rob's
existing system. Could I sell that? Probably. Intellectual property
includes "know-how", but, hell, I owe everybody that's answered my
questions, and for those many answers I've lurked too.

        If you have any questions or problems, I'll help as I can. You
can reach me on DOVE-Net Sysop's, or on my board at (415) 589-5705, or via
internet e-mail: symbolist@comm-net.com. (AKA tom.hill@comm-net.com)

        Enjoy your rooms! They can add a unique capability to your
system, and when you think of another use for this technique let me know
about it!

                               __ end __
--------------------------------------------------------------------------
(c) 1994 by Tom Hill. All rights reserved.


