Big Blue Disk 22/bbd22.zip/DESK.TXT

Text File | 1988-05-23 | 11KB | 166 lines

|D╔══════════════════════╗════════════════════════════════════════════════════════
|D║ |5On the Editor's Desk |D║════════════════════════════════════════════════════════
|D╚══════════════════════╝════════════════════════════════════════════════════════

^C^1On the Editor's Desk
^Cby
^CDaniel Tobias

   In this column, I give news and reviews of products and developments that
have reached my desk.

   A major element of the computer industry news lately seems to be a wave of
litigation.  It seems everyone in the industry is suing everyone else these
days.  First Lotus sued some other software companies over the "look-and-feel"
issue of software copyrights, even though its own look and feel was largely
taken from the earlier VisiCalc program.  Now, Apple is suing Microsoft over
alleged violations of its copyright to the Macintosh user interface, even though
^1that^0 was largely taken by Apple from an interface developed by Xerox in their
PARC laboratories.  All of this is a shame.  In the old days when hackers
controlled the field, everyone worked together in a spirit of cooperation; the
competition within the industry was a friendly rivalry between fellow
enthusiasts, fought on a technical level as everyone tried to come out with the
most ingenious new hardware and software products.  Now, with personal computers
a big money field, the whole complexion is different; while the "techies" may
still prefer hacking to litigation, they no longer control the corporations that
their 1970's enterprises have evolved into.  These days, corporate lawyers
control legal policy in the computer industry, and everyone else is the loser.

   There's another case presently in the courts which, while it's not getting as
much press as the Apple/Microsoft battle, will create important precedents with
regard to the legal status of bulletin board systems (BBS's).  Linda Thompson of
Indiana has sued Bob Predaina, the sysop (System Operator) of the Professional's
Choice BBS.  In this suit, she alleges that the sysop exposed to public view a
number of private messages she exchanged with another user of the BBS.  It is
also alleged that the sysop terminated her access to the system (presumably
after she complained about her private messages being exposed) even though she
had paid a fee which was supposed to guarantee her access for a year.  This case
is interesting in that it's the first one involving BBS's to be filed under a
recently-passed Federal law guaranteeing privacy of electronic mail.  Existing
laws guarantee privacy of older forms of communication like paper letters and
phone calls, but E-Mail was formerly unprotected from snooping, whether by
private individuals or government agencies.

   This law is primarily intended to apply to commercial E-mail services like
MCI Mail and CompuServe.  BBS's, while they provide similar services, are
usually run by hobbyists, and are generally much more informal.  However, they
are still E-Mail providers, and hence subject to the same law.  This means that
users who enter private messages have some legal guarantees of the privacy of
these messages.

   If the allegations in this suit are correct (I haven't seen any statement by
the sysop in question, so I have no way of knowing the merits of the case), then
the sysop was acting in a highly unethical manner, and probably deserves to be
sued for it.  However, I hope that this case doesn't have repurcussions that
lead to BBS's being entangled in legalese and government regulation.  A hobbyist
running a BBS in his spare time can't exercise the same level of care that a
multi-million dollar corporation puts into its commercial service, and slipups
might be made that can be construed as violations of various laws, such as
accidentally including private messages in a publicly-viewable listing.  One
hopes that lawsuits under the E-Mail privacy law remain limited to cases of
gross violations with malicious intent rather than simple mistakes, but given
the state of litigation in general these days, I kind of doubt it; there may end
up being such a rash of litigation that many "hobbyist" sysops end up shutting
down their systems for good.


   Product review department:  For years now, we've been producing products
sometimes referred to as "magazines on disk."  Well, now, Infocom (125 Cambridge
Park Dr., Cambridge, MA 02140) has come up with a new twist on this genre, with
a line of ^1comic books^0 on disk.  The ^1Infocomics^0 series consists of
stories told with words and graphics on your screen.  They're not adventure
games: the story has only one ending, which you can't affect.  However, you
^1can^0 change viewpoints at various points in the story, switching from one
character to another.

   The one I looked at, "Gamma Force in Pit Of A Thousand Screams," featured the
origin story of a team of three superheroes arising to overthrow the oppressive
dictator of their home planet.  It wasn't great literature, but the intended
audience of youngsters should find it interesting.  I suggest you make few
viewpoint shifts the first time through (when I took advantage of all shift
opportunities I rapidly got totally lost, viewing the ongoing adventures of
characters who I didn't even recognize), and then go back and go down other
paths to get the rest of the story.  Some plot elements don't become entirely
clear until you've seen them from more than one angle.

   It's basically a fun idea.  However, I wonder if they'll sell many at the $12
price tag; regular paper comic books are still available for as low as 75 cents.
Even the high-priced "graphic novels" of the comic book world are usually less
than $12, and offer better story and art (the IBM's CGA is sorely limited in
color and resolution).

   One more thing: as a comic fan myself, I'd like to point out that simplistic
stories, such as those found in the InfoComics, are not the only kind of "comic
book" stories there are.  Recent comics like DC's "Dark Knight" and "Watchmen",
and many overseas comics in France and Japan, show a great amount of sophistic-
ation, and have many adult readers.  I hope, if Infocomics are successful, that
they don't have the unfortunate effect of reinforcing the public impression that
comics are just "kid stuff."  Maybe Infocom (or another publisher) can try
producing some more-adult material (in the sense of increased intellingence and
sophistication, not necessarily sex and violence) in a similar format of a
graphics-and-text storyline accessible by multiple viewpoints.


   Followup department:  A couple of months ago, I reviewed Procomm-Plus from
Datastorm Technologies.  Since then, I have made some more involved use of its
script language, Aspect, to write complex scripts involving the automated
transfer of electronic mail.  While I still think the program and its script
language are very good, I found some serious flaws I'd like to point out.

   First of all, when you use the script command FGETS to read a line from a
text file, it comes out with a linefeed at the end.  This causes problems when,
for instance, you need to read from disk the name of a file you wish to download
or upload; the file handling commands don't like linefeeds at the end of the
names they use.  The only way around this that I've found is to read the name
one character at a time, stopping when a linefeed is reached without appending
it to the string.  Unfortunately, this is very slow, since it involves doing a
loop with GOTO statements, which requires a scan of the entire script file to
find the place to go to.  This can be speeded up somewhat by placing it near the
beginning of the script file, but it can still cause a simple input to take as
much as 30 seconds, where it would have taken less than a second if FGETS could
be used.  This is not very desirable if you're in the middle of a long-distance
connection, or online with an expensive commercial service.

   There also appears to be a problem with incoming characters sometimes being
lost while Procomm+ is in the middle of doing other operations in a script; this
can cause the "WAITFOR" command to wait forever for a target string that's
actually already come, if it comes too quickly after the previous command in the
script was reached.  This can generally be remedied by careful crafting of
script files, for instance by doing any lengthy computations or other operations
before the carriage-return is sent to the modem to signal the remote service to
start sending more information.

   Finally, I haven't found a very good way to output an end-of-line sequence
(Carriage Return and Linefeed) to a text file being written to from a script.
The caret sequences ("^^M") which work in sending text to the modem are not
supported in the commands to send lines to a text file.  This is a problem when
you want to create a text file with multiple lines.  The only way around this I
could figure out is to create a file LINEFEED.TXT containing a linefeed
character, then read it into a string variable at the start of your script, and
output that string whenever you need a CR/LF.  (The Carriage Return apparently
gets added automatically when a Linefeed is sent.)

   I called Datastorm's technical assistance department, and after considerable
deliberation (and placing me on hold at long-distance rates several times), they
finally told me that the linefeed-on-input-string matter was a real problem that
they hadn't been aware of, and that they would fix it in the next release.
However, since the present release (1.01A) is already out, there's no telling
how long it will be until the next release.  In their attempts to solve my
problem, at one point one of their programmers suggested that I use the STRLEN
function to get the length of an input string in order to use SUBSTR to remove
the linefeed.  Problem is, there isn't any STRLEN function in Aspect.  That's
another thing they plan on adding in the new revision, now that I've pointed it
out to them.

   Regarding the output of linefeeds, they told me to use "BINARY" files instead
of "TEXT", and that the "caret" commands would work in this case.  I tried it
afterward and it didn't work.  Maybe the new revision will take care of this by
enabling caret sequences in disk I/O strings as well as modem I/O.

   Anyway, despite these flaws, I still find Procomm+ to be an excellent
program, with many powerful features, and these flaws shouldn't get in the way
of most users with less demanding tasks that don't require scripts that read and
write text files on a line-by-line basis.  But if you do wish to make use of the
full sophistication of the script language, then maybe you should hold off
purchase of Procomm+ until the flaws are fixed in a later version.