textfiles/computers/designer.txt

SAPPHIRE DESIGNER NOTES by Tim Campell.

This section contains no especially important information.  It is presented
here  for those people who might want to know why Sapphire was designed the
way it was.

Some Background

I've been  involved with computers since  1971, and since those  early days
spent sweating over a 10 character-per-second Teletype, my enduring passion
has been computer telecommunications.  I'm fascinated by the way it enables
us to reach out and grasp the crystallized thoughts of  a stranger.  We can
enter an amazing,  exciting universe.  Where  time can stand still  or flow
sideways.  Where people  can flash across  a continent in  the blink of  an
eye. 
Over the years, I've worked out countless designs for computer telecommuni-
cations systems.   Several of these designs  went beyond the planning stage
and became reality.   It excites me that we basement  programmers have this
chance to pioneer new methods of communication.

Some of the projects I've been involved with include:

    ACCESS:   Canada's first national consumer telecomputing service.

    PYROTO:   The BBS/Game system (about 50,000 people play it each week).
              The latest version  is available from Pinnacle  Software for
              $35.  (Runs also as a door.)

    SASSy:    A bizarre experiment  that helped us learn  what's wrong and
              what's right about  BBS's.  The spec and a 2-year report are
              available from Pinnacle Software ($10).

I also had  the chance to provide  some suggestions for Ron  Sharp's extra-
ordinary INFINITy system,  which is a BBS with  a seemingly infinite number
of message bases.


Why Sapphire was Written

After years of seeing other  kinds of BBS's, I had  to admit that I  didn't
like the way any of them worked.  I'm not talking about minor annoyances --
my own program has  dozens of quirks that I intend to iron out. Rather, I'm 
talking about fundamental design decisions.

To my knowledge (and  based on my interpretation), every single  one of the
existing BBS  packages evolved from  RBBS.   Perhaps not in  actual program
code, but certainly in concept.  They all share the same  general features,
though admittedly most are vastly superior to the original RBBS!

I was never tempted to copy RBBS,  because I'd already written my first BBS
program long before anybody around here  knew what a BBS was.  It  wasn't a
very sophisticated program, but it did put me on my own path.

It  is  important to  understand  that there  was  something of  a computer
revolution  in Montreal  during the  mid-to-late 70's.   A large  number of
hackers set up  house on a local  school board's HP2000 mini-computer.   We
evolved our own set of idioms, so when the first "mainstream" BBS (an Apple
Networks) came to  town, we said, "BBS?   What's that?   Bulletin Broadcast
System?"  We really didn't know!

Our user-interface idioms found  their way into various programs  that were
developed locally.   And thus they were  found in ACCESS, then  PYROTO, and
finally (after considerable mutation) in Sapphire.


Notes About the Design Philosophy

Commands

Sapphire uses word commands, rather than single-letter commands.  I figure:
it's easier to remember words than mnemonics -- especially when the mnemon-
ics are tortuously contrived (as in the infamous [Y]ell for chat).

Since you  don't run out of words the way  you run out of letters, Sapphire
doesn't  need  multiple program  layers where  the  same commands  can mean
different things (e.g. [U]tilities or [U]pload), depending where you are.

Because I use  word commands, I tend to make Sapphire somewhat more conver-
sational than a letter-command system.   I should mention that  some people
find my programs fairly terse.  What I  mean to say is that, while Sapphire
is not chatty, it  is more like  a dialogue than you're  likely to find  on
most BBS's.

Maintenance

Sapphire  is a zero-maintenance BBS.  I  design programs this way partially
because I'm  lazy and partially because  in the 70's most  Montreal hackers
were in a position to  get cut off from their programs at any  time.  (Most
of us weren't really supposed to be on that central system.)   As a result,
my associates  and I  got in  the habit  of designing  programs that  could
survive on their own.

40 Column Text

Many people have expressed  surprise at my extensive use of 40-column text.
The obvious answer  is that there are still plenty of 40-column screens out
there; the IBM-PC isn't the only personal computer in the world.

However, the real  reason is that when people are reading boring text (such
as is necessary  while learning  to use  a BBS), they  want to  scan it  as
quickly as possible.   The fact is,  80-column text requires too  much eye-
movement for easy scanning; if newspapers can use narrow columns, so can I.
Why  should I be  held hostage to  the actual width  of my screen?   No law
forces us to fill each line.

The Cool Reception

The way  by which  potential members  are  introduced to  Sapphire may  not
strike you as  particularly inviting.  They are requested to send a message
telling you why they'd like  to join.  A few  people are so offended,  they
hang up immediately.

The actual requirements for the application  can easily be changed, though.
Maybe you'll merely ask  them to tell you their  shoe-size.  But if  you're
running your BBS as a public service, I'd advise against it.

The vast majority of BBS's  go down within a few months because  the sysops
are appalled at the  uncaring nature of the users.  But what can we expect?
Total strangers call our boards; should we expect them to be nice to us?

You  can greet them  all with  open arms, but  chances are, you'll  be very
disappointed.   These  anonymous people  simply  have no  particularly good
reason to think you're special.

Far  too few  novice sysops  are aware  of the  simple  fact that  when you
figuratively  "throw  open your  doors", you  can  get crumbs,  bums, free-
loaders, and jerks.   You also get some beautiful people,  but it's hard to
remember that when you've got some fellow who signs on, makes a beeline for
the  files section,  and ties  up your  line for hours  as he  pilfers your
software collection -- leaving nothing in return.

It is utterly futile to be bitter.  The best solution is to be careful.

A sysop's worst enemy  is his own good nature.  He wants to spread his arms
and hug everybody who signs up to his  system.  At first, he's excited that
so many people are visiting his BBS.  But later, when he  realizes how many
people  treat him  like  a bus  service  for software  and  information, he
becomes disillusioned.

Perhaps I'm wasting my time telling this to new sysops, but the experienced
sysops  will be  nodding their heads,  by now.   The  fact is:   either you
resign yourself  to being used as  a commodity, or you learn  the very dif-
ficult art of rejecting new applicants.

Of course, what  percentage you reject depends  on the size of  your BBSing
community.   In Montreal,  we have  plenty of people  calling BBS's.   As a
result,  I'm easily able to  reject 95% of all applicants.   Mind you, that
means that for the  first 2 months, my BBS was  excruciatingly dull.  After
all, how lively can a BBS be, when it has only a handful of members?

Happily, though, I  stuck to my  guns.  Nowadays, The  Pinnacle Club has  a
nice  mix of  people, all  of  whom are  what most  sysops  consider "ideal
BBSers".  It  almost took more  patience than I  possess (since, like  most
sysops, I have an urge to let everybody on), but it was worth it.

What makes  Sapphire truly a "Zero-Maintenance  BBS" is that you  can judge
people  by their reaction  to the request that  they justify their petition
for membership.  You don't even  have to phone them up!  What  people write
in their application usually tells the whole story.

For example, many people  write things like, "Hi, I'd like  to be a member.
Please make me a member.  Thanks."

If such a person can't even be bothered to justify himself, it is extremely
unlikely he will make an effort to be a good, contributing member.

I've  had some extraordinary  experiences with  this method  of validation.
One fellow was incensed at the impersonal approach, but he took the time to
express his objections  in detail.  Bingo!  I made  him a member.  He later
posted a  message to the effect that he thought  he'd "gone to BBS heaven",
so impressed was he by the quality of the messages left by members!

Sapphire can  be easily modified to  be less daunting  to the new user.   I
don't want  to give  you the  impression that  Sapphire must  give all  new
applicants the cold shoulder.

But if you're a new sysop, I hope you'll think about the kind of people you
want on your system and design  accordingly.  Ask a few experienced  sysops
for advice.

Conclusion

Sapphire is not complete.  There are numerous upgrades to be made.  Some of
these are summarized in Appendix C.

However,  I would like  to make it  clear that it  is not  my intention for
Sapphire  to be all  things to all people.   I hope  to retain the apparent
simplicity of the design.

In other  words, there are many other BBS  packages out there that are more
grandiose in intent.  They can make your microcomputer look like a whopping
big mainframe.  But if you want a BBS  that is easy for your users and easy
for you, I think you'll want to run Sapphire.