From: kgermann@zeos.com (Ken Germann)
Subject: COCONET.
Organization: Zeos International, Ltd
Date: Thu, 15 Oct 1992 13:36:41 GMT

I have no affiliation with COCONUT Computing or the COCONET software.
This information is being provided at the request of several users of
the internet that have expressed an interest in COCONET 4.0. As as
service to them and to others that have asked about a "good"/"great"
bbs software, I am providing this release. The 4.0 release is due to 
ship on the 16th of November or sooner. Any questions about this
can be directed to Brian Dear at brian@coconut.com.

An applications developer that is seasoned in programming the 
COCOTALK language beside Brian, is Bruce Woodward (bruce@cyberstore.ca).
Bruce has developed/is developing a large array of applications for
COCONET. They (Cyberstore) also have developed a set of their own development 
tools and does custom work.

Brian Dear - President of COCONUT Computing, brian@coconut.com

Bruce Woodward - Partnet in CyberStore, bruce@cyberstore.ca.

Please direct your questions to these individuals. I hope that this 
information is found to be informative.


>>>>> What's New in COCONET(R) 4.0

* General enhancements to COCONET HOST program

HOST redesigned with a new modular architecture In Version 3.2,
the COCONET HOST program was the primary program that
controlled all activities while a user was online.  The 3.2
HOST  contained practically all of the features and functions
of COCONET in one single program, with the exception of the
UserBase(tm) database and the SYSOPS (system operator options)
external programs.  Beginning with Version 4.0 of COCONET, the
COCONET HOST program plays just as important a role, but a
different role nevertheless.  Whereas before, the HOST did
practically "everything", the new HOST delegates control to
subordinate module programs, one program per major COCONET
function.  The new HOST program can be thought of as the
"conductor" or "orchestrator", constantly  monitoring the
status of the user and determining which module should next be
run.  There are several benefits to this new approach: the HOST
program itself is much smaller than it was in Version 3.2, and
therefore it uses less memory and disk space when in use.  It
is also easier to maintain, since its role is much better
focused and defined.  Each module, such as PMAIL for Personal
Mail, DISC for Discussions, FILEX for File Exchange, is a
separate, independent program.  Keeping the programs separate
means that they stay small and use less memory.  Also, it means
they can be independently updated, without having to worry 
about updating other modules at the same time.  The old
approach required updating the entire HOST program even if only
one specific part of the HOST needed updating.

* Sysop can now still sign on even when the simultaneous user limit is reached

In past versions, it was impossible for the sysop to sign onto
COCONET if the maximum number of users was already signed on. 
Beginning with Version 4.0, it will be possible to sign on as
a sysop even if all of the lines are in use by regular users. 
Also, should the case ever arise that a) the sysop is already
signed on, b) the maximum number of simultaneous users is
actually reached, and c) a non-sysop user is attempting to sign
on, the COCONET HOST program will allow the new user to sign
on, at which point anyone else signing on would be told that
all lines were busy, followed by the suggestion to "try again
in a few minutes."

* Greatly enhanced and entirely rewritten documentation

Many customers have commented about the need for additional

explanations and descriptions in the COCONET HOST
documentation.  For Version 4.0 of the COCONET HOST program, an
entirely new manual has been written -- from scratch. 
Reorganized, rewritten, re-everything.  We are confident that
the new manual will serve both as an excellent introduction to
the product as well as an excellent reference whenever
questions or problems arise.

* Support added throughout for Apple(R) Macintosh(R) version of Access Program

In order to be able to support a COCONET Access Program for
Apple Macintosh, we had to redesign portions of the internal
workings of our CocoTalk(tm) API C Library and COCODE(tm)
presentation/communications protocol, to take maximum advantage
of all of the great features built-in to the Mac.  We also made
the changes so that in the future when we release COCONET
Access Programs for other graphical user interfaces, much of
the underlying work will be already done.


Main Menu Display and Main Menu Menubar
---------------------------------------

* Features Menu editor replaced with a full Main Menubar Editor



Customers familiar with the Features Menu Editor that was
available in Version 3.2 of COCONET will be surprised to
discover that it has been entirely replaced by a much more
powerful Main Menubar Editor, which will allow the sysop to
customize the entire main menubar rather than just the Features
menu portion of the menubar.


* Create up to 16 popup menus, each with up to 28 items

Sysops can now create up to 16 different menus on the menubar. 
Each menu has its own name and can have up to 28 items on it. 
Each item, in turn, also has its own name as well as a unique
destination type.  Destination types include: "CocoTalk
external program", "non-CocoTalk external program", "DISC",
"PMAIL", "FILEX", "TextFileBrowser", etc.  In addition, each
item contains its own access list (see next paragraph for more
information).


* Separate access control for every menu and menu item

Each menu and each item on each menu contains a unique access
list to control the access to that menu or item.  When a user


signs on, the HOST program determines what Access Groups the
user is rostered in, then reads the Main Menubar's data file,
and quickly determines what the Main Menubar will look like to
this user, based on his or her access.


* Hide certain menus or menu items from unauthorized users

If some menus or items on menus are designated as "hidden",
then only if the user is explicitly given access (either by
name or by being rostered in an Access Group that has access)
will the user actually see that menu or menu item.  Otherwise,
the user will not even know such a menu or item exists.  In
cases where all items on a menu are hidden, and the user has
access to none of the items, then the whole menu is hidden also.


* Option added to create entirely customized main menu module

In addition to the new Main Menubar Editor, it is possible to
not even use a Menubar at all, but rather to substitute the
menubar with a complete custom application which the HOST will
treat as its "Main Menu".  The  custom application would need
to be written with the Version 2.0 of the CocoTalk API C
Library.  Version 2.0 of CocoTalk contains new functions that


allow the programmer to designate which "destination" was
chosen by the user, so that when the custom application exits,
the HOST will call the proper destination, just as if it had
been called by having the user select a menu item off of the Main Menubar.


UserBase database
-----------------

* Many new sysop options added

Prior to Version 4.0, sysops had to use the User Records
Management options in the SYSOPS external program in order to
add, delete, modify, or simply inspect user records.  Beginning
with Version 4.0, user records management tasks have been moved
to the UserBase database program.


* Users can specify up to 5 keywords

Each user's data record contains space for 5 special keyword
fields. These can be used so that other users, including
sysops, can search the UserBase database by one keyword or by
some combination of keywords.

* Custom fields available for each user record

A good amount of space has been reserved in each user data
record for  custom applications.  Primarily intended for
special applications that combine the CocoTalk API Library with
a database toolkit, these reserved fields allow the system
administrator to save information such as credit card numbers,
birth dates, or other information required for their application.


* Each user can have his or her own "resume" file attached to their record

Another feature making its debut in UserBase is an ability for
each individual user to provide a lengthy text description of
their interests, career highlights, etc.


* Optional image file can be associated with each user

In addition to a biographical "resume" file attached to each
user's UserBase record, an optional image file can also be
attached.  One such use of this image file would be to allow a
scanned portrait image of each user.

* Searching options perform much faster now

Because the new UserBase employs a real database engine with
real database index files, searches are not only faster, but it
is now possible to offer search capability on a number of
fields.  For instance, it will now be possible to search for
all users located in "New York"  or "London" or some other city.

* Sysop can control who has access to UserBase

The sysop can now specify who has access to UserBase.  It may
be that you do not wish users to be able to get information on
other users, perhaps because of privacy concerns.  Whatever the
reason, the sysop has complete control over who gets to use
UserBase and who does not.

* Now uses industry-standard .DBF and .MDX data file formats

As with many other features of COCONET Version 4.0, UserBase
now makes use of industry-standard dBase-style file formats,
rather than a proprietary format.  This makes it possible to
access, read, and/or manipulate the data files in ways not


before possible.  For instance, if you have dBase IV for UNIX(R)
on your system, you could access the database files and search,
sort, or generate statistical reports based on the data
contained in the files.


* Now written as an external program module with CocoTalk API

Like so many other modules with Version 4.0 of COCONET,
UserBase is  written using the CocoTalk API C Library.

System Operator Options Reorganized
-----------------------------------

* Many sysop options moved from SYSOPS program to various modules

Many customers have commented to us over the years that they
did not like having to exit from a particular location on the system,
say, the List of Discussions, and go all the way back to the Main
Menu, then enter the special SYSOPS options, and then traverse
some more menu layers before reaching options to manipulate or
act upon the thing that they just were forced to leave, again, such
as Discussions. What we have done in COCONET Version 4.0 is
put the sysop options where they belong.  Options to add, delete,
modify, and otherwise manipulate Discussions are now located
within the Discussions feature. Options to add, delete, modify, and
inspect user records are no longer in the SYSOPS program, but
are now where they belong, namely, in UserBase.  Since some
sysop options were already done this way, we felt it would be
consistent if all options were done this way.


File Exchange
-------------

* Multi-file "Batch" downloading option added

Beginning with Version 4.0 of COCONET, it will be possible for
users to select a collection of files before actually beginning to
"receive", or download, them.  This way, users can "browse" the File
Exchange library at ease, picking files here and there that they're
interested in having sent to them.  When they are ready to actually
receive all of the files, they simply select a new menu option to
"Receive" the "batch" of files, which will be transmitted in sequence
to the user.


* Optional automatic signoff at end of file transfer added

With COCONET Version 4.0 it will now be possible for users to
indicate that at the end of a file transfer, the COCONET Access
Program should automatically disconnect from the COCONET
HOST system that it is connected to.  When such is the case, the
HOST will automatically log the user off, close his or her files, and 
then cause the Access Program to go "off-line".


* Enhanced access controls added such as "hiding" areas/subareas

As is the case elsewhere on the system, one access control feature
available for the first time in COCONET is the ability by the sysop
to designate that certain File Exchange areas and/or sub-areas are
to be "hidden" from view, except for those users or Access Groups
who are allowed access.  Thus, it will be possible to offer private
File Exchange areas and sub-areas.


* Option added allowing users to search for "new" files

A new option has been added to COCONET Version 4.0 to allow
users to search for files in any area or sub-area that were recently
added to the system.  The user simply specifies a "since" date, and
the system then lists only those files that have been added "since" that date.

* Up to 999 file areas can now be created

Each file area is a "category" in which you can organize your files.
With Version 4.0 of COCONET you can have up to 999 different file
area categories.

* Up to 999 sub-areas can now be created in each area

Inside each of the 999 File Exchange areas, you can now create up
to 999 "sub-areas" (or "sub-categories"), inside each of which you
can put files.

* Up to 999 files can be added to each sub-area

Inside each of the up to 999 sub-areas inside an area, you can list
up to 999 files.  This means that the File Exchange supports
999x999x999 files, which works out to be some 997 million files.

* Each file can now have a long description text file associated with it

When a file is added to the File Exchange, an optional long
description text file may be attached to the file's data record and
then displayed whenever the file is selected by a user.  One use for
this feature is to describe in-depth exactly what is in the file, or, if
it is a program file, what exactly the program does and does not
do.  Another use for a long description would be to provide
instructions on how to install the file on the user's computer.

* Each file can now have up to 5 keywords associated with it

Much like the new feature in UserBase, each file in the File
Exchange database can have up to 5 separate keywords
associated with it.  Users can then search for files by entering one
or more target keywords to search for.

* Specify different subdirectory for each subarea

When the sysop creates a new sub-area within a File Exchange
area, he or she can specify in what path all files listed in this sub-
area are located.  Thus, each sub-area can have its own path. 
Some paths may be on completely different computers that are
networked together; other paths may point to CD-ROM
subdirectories (we recommend SCO(R) UNIX 3.2.4 for CD-ROM use).
                                                          
* Now uses industry-standard .DBF and .MDX file formats throughout

Whereas Version 3.2 and earlier versions of the COCONET HOST
relied on a proprietary, nonstandard file format for keeping track of
files in  the File Exchange, Version 4.0 introduces a completely new
approach using the standard and familiar dBase data and index file
formats.

* Now written as an external program module with CocoTalk API

Like other modules in this new "modular" COCONET, with Version
4.0, the File Exchange is a separate external program written using
the CocoTalk API C Library.


* External programs for entering and exiting both areas and subareas

In Version 3.2 of the COCONET HOST, it was possible to assign
a CocoTalk external program to each Discussion on the system. 
Whenever a user "entered" that Discussion, the program, if present,
would run and display whatever the program was designed to
display (often some sort of "title" or "welcome" screen).  With
Version 4.0 of COCONET, this capability has not only been
extended to the Topic level of the Discussion feature, but also to
both the area level and subarea level of the File Exchange.  Which
means whenever a user "enters" or "opens" an area or sub-area
that has a special CocoTalk external program assigned to it, the
program will run until it exits, at which time the File Exchange will
resume where it left off (i.e., it would then either show the list of
sub-areas if the user had selected an area, or a list of files if a user
had selected a sub-area).  Likewise, whenever a user "exits" an
area or subarea that has a external program associated with it, that
program will run.


Personal File Exchange
----------------------

* Sysop can now see Private areas

With Version 4.0, the sysop can now access all Personal File
Exchange areas, both Public and Private.


* "Batch" downloading option added



The same "batch" feature that has been added to the general File
Exchange has also been added to the Personal File Exchange,
which means that a user can go into his or her Personal File lists
and select multiple files for downloading.


Personal Mail
-------------

* External UNIX/Internet email support added

Perhaps, at least for some customers, the most significant new
feature coming in the Personal Mail facility of COCONET Version
4.0 is the support for UNIX email.  No longer do COCONET HOST
systems have to be isolated from the rest of the "world".  If the
UNIX operating system, on top of which the COCONET HOST is
running, is connected to a UUCP or Internet node, then "local"
COCONET users, who do not have UNIX user IDs themselves, will
be able to send and receive mail to and from "remote" users on
other computer systems and networks.  It is the responsibility of
the UNIX system administrator to make sure that the UNIX mail
subsystem is delivering mail to the remote users.  What COCONET
will now do is permit "local" COCONET users to specify a remote
user's full Internet-style email address, type in a message, and then
send it just as they would Personal Mail to another local user.


* Each user can now have mail from up to 999 different "correspondents"

The limit of how many "correspondents" an individual user could
receive mail from has been expanded to 999.  This means that
users can conduct Personal Mail correspondence with up to 999
other users at any one time.


* Users can now have up to 999 messages from each correspondent

Up to 999 messages may be stored from each of the 999
correspondents that a user is corresponding with.


* Each user can now have up to 998,000 Personal Mail messages total


Nearly one million Personal Mail messages is an awful lot of mail --
especially considering that is how many possible mail messages
each user can have!  Because of the potential for substantial disk
storage space requirements for such a large number of messages,
Version 4.0 of COCONET offers the sysop the ability to limit how
much space each user may have for Personal Mail.  Thus, it might
be that a user may only be allocated 250,000 bytes of storage
space by the sysop, which might mean that the user would have
to more frequently "purge" old messages in order to prevent their
Personal Mail mailbox from filling up.  To assist users with this
cleanup process, a new option has been added to allow users to
"remove old messages" past a certain date that the user specified.


* Messages no longer limited to 25 lines; can be up to 64 Kbytes long

One long-standing complaint of customers has been that Personal
Mail and Discussion Topic messages were both limited to only 25
lines of text. The 25-line barrier has finally been broken with the
release of  COCONET Version 4.0: in the new release, the number
of lines is no longer regarded as an issue.  The limit has been
changed to a maximum of  64,000 bytes per message, or the
equivalent of approximately one thousand lines of text where line
each averages about 64 characters.


* Users can now search for a particular word or phrase in messages

Another long-standing request of users was that we add the ability
to search for a particular word or phrase within all Notes and
Responses inside a Discussion Topic.  With Version 4.0 of


COCONET, you can do precisely that.  The new option will allow
the user to enter a string of characters with which to search.  All
messages that contain the search string will be listed in the List of
Notes.  This option should be particularly useful now that individual
messages can each be 64,000 bytes long.


* Users can also now search for a particular word or phrase in subjects

This option is similar to the new "search for text in Note titles"
option available in the Discussion Topics.  Users can now enter a
word or phrase and the system will search for, then list on the
screen, all messages whose subjects contain the word or phrase. 


* Options to create your own mailing lists added

Users can now add, delete, and modify their own Mailing Lists.  A
Mailing List is simply a file that contains a list of user names (both
local COCONET user names and Internet-style email addresses). 
Each Mailing List can be assigned some name.  Then, whenever
the user wishes to send mail to all users in that list, he or she
simply needs to type in the name of the Mailing List, instead of re-
typing all the individual users' names. 

* Users can now bypass menus and jump straight to unread messages

Another perennial request of customers was that we add a
capability to "skip" the menu levels and jump straight to the first
unread message in the user's Personal Mail mailbox.  Beginning
with Version 4.0 of COCONET, this option exists.  If you have
unread mail, you can go straight to it from the main Personal Mail
menu, rather than having to traverse several menus before seeing
the message.  Also, we have added a new item to the "Read" menu
seen while reading mail.  The new option allows you to skip to the
next unread message, regardless of whether or not it is from the
current correspondent or some other correspondent.  This "skip to
unread" option automatically disables itself once you have read all
unread messages.


* "cc:" (carbon-copy) option added

Closely related to the new Mailing List feature in Personal Mail is
the new "cc:" feature.  When you compose a new mail message,
you may now optionally indicate that the message should be "cc'd"
to one or more user names and/or Mailing Lists.

* Mail forwarding option added

Beginning with Version 4.0 of COCONET, it is now possible to
"forward" a message to another user or set of users, while you are
reading the message. A new option on the "Action" menu allows
you to "Forward this message" to one or more users or Mailing
Lists.


* Users can now add a "vacation" message seen by future correspondents

Oftentimes it is useful for a user to temporarily display a message
so that anyone who tries to send mail to him or her is first shown
a message.   Often this message announces that the user is on
vacation or is simply not able to respond to messages quickly for
some period of time.  This feature, new with Version 4.0 of
COCONET, is available to all users as an option.


* Users can also add "no room" message if their mailboxes get full

Closely related to the "vacation" message option is another option
allowing users to create a special message to be seen only when
their Personal Mail mailbox gets full.  This option is new with
COCONET Version 4.0. 




* Now uses an improved text editor for both text and graphics users

In order to eliminate the 25-line-per-message limit that was present
in all earlier versions of COCONET, it was necessary to completely
re-write the editor in the COCONET Access Program as well as the
text editor for non-graphics users.  These new editors are capable
of working with messages of up to 64Kbytes in size.

* CocoTalk external programs can now "send mail" to a user

A very powerful new function developed for Version 2.0 of the
CocoTalk API C Library is MailMessageSend() option, which allows
the programmer of any CocoTalk external program to take any
buffer or text file (up to 64Kbytes in size) and have it automatically
sent to a specified user as a mail message.


* Option added to "get info" on a correspondent while reading messages

In COCONET Version 4.0 users can, while reading messages from
correspondents, call up the UserBase data record information on
any other user to find out who they are, etc.  (This assumes that


the sysop has allowed UserBase  access to users).


* Messages can now have "attachments" (files, etc.)

Beginning with Version 4.0 of COCONET, it is now possible to
"attach"  additional files to your Personal Mail messages.  These
"attachments"  can either be additional text files, graphics images,
audio files, or binary data or program files.


* Sysop "message-to-all-users-on-system" option added

This option allows the sysop to "broadcast" messages through
Personal Mail to all users on the system.  When each user signs on
the next time, they will discover that they have unread mail from the
sysop.  Rather than have COCONET send potentially thousands of
copies of the same message to all users on the system, "sysop
broadcast messages" are treated differently --only one copy is
actually placed on the system, yet each user's mailbox will think it
has its own copy of the message.  


* Sysop can now specify a default "welcome" message for new users



Similar to the new "sysop broadcast Personal Mail message"
option, this option allows the sysop to specify a Personal Message
seen as unread mail by all new users.  Again, only one copy of the
message is actually stored on the system, to save disk space.


* Now uses industry-standard RFC-822 and 1036 formats for message files

Beginning with Version 4.0 of COCONET, Personal Mail uses the
Internet standard RFC-822 and RFC-1036 file formats for
messages.  Coconut has added its own extensions to the headers,
in compliance with the RFC  standards.  No longer will Personal
Mail files be stored in a nonstandard, proprietary format.


* Now uses industry-standard .DBF and .MDX formats for data files

For recordkeeping and indexing, Personal Mail is now using
industry-standard dBase-style data and index files.  The fields and
records are documented in the new reference manual
accompanying the CocoTalk API C Library Version 2.0.


* Now written as an external program module with CocoTalk API



Like so many other modules with Version 4.0 of COCONET,
Personal Mail is  written using the CocoTalk API C Library.  It is
now a separate external program called PMAIL.



Discussions
-----------

* Up to 999 Discussions can now be created

The sysop can create up to 999 different Discussions.  Discussions
are high-level categories inside of which up to 999 different
"Topics", or message forums, can be created.


* Up to 999 Topics can now be created within each Discussion

Each "Topic" within a Discussion is a complete, self-contained
"message forum" or "conference".  Thus, it is possible to have up
to 999 separate forums within each of your 999 Discussion
categories.  This means that COCONET Version 4.0 supports up
to 997,000 different message forums.




* Up to 999 Notes can now be created within each Topic

Within each Discussion Topic, up to 999 Notes can be written. 
Each Note is essentially a separate "conversation".  Each "Note"
message can have "Response" messages appended to it.


* Up to 999 Responses can now be appended to each Note

Inside each Discussion Topic, users can append up to 999
Responses to each of the 999 Notes.  This means (in theory, at
least) that each Discussion Topic can essentially handle some
997,000 messages.

* Nearly one trillion messages total

Since there can be 999 Discussions, and 999 Topics within each
Discussion, and 997,000 messages inside each Topic, this means
that the entire system, in theory, can support up to nearly one
trillion messages.  Sysops may not yet have the disk space for so
many messages, but what it means more importantly is that they
won't have to worry about reaching COCONET's limits any time
soon.




* Messages no longer limited to 25 lines each; now can be up to
64Kbytes long

One long-standing complaint of customers has been that Personal
Mail and Discussion Topic messages were both limited to only 25
lines of text. The 25-line barrier has finally been broken with the
release of  COCONET Version 4.0: in the new release, the number
of lines is no longer regarded as an issue.  The limit has been
changed to a maximum of  64,000 bytes per message, or the
equivalent of approximately one thousand lines of text where each
line averages about 64 characters.


* Enhanced access controls added such as "hidden"
Discussions/Topics

The sysop can now specify that certain Discussions be considered
"hidden" for users who do not have access to them.  The sysop
can now also specify the same for Topics.  When a user signs onto
COCONET, the COCONET HOST program will scan what Access
Groups the user is rostered in.  It then reads the list of Discussions
and determines which Discussions the user should see and which
he or she should not see in the list.  This searching is done once
each time the user signs on, to improve the overall performance of
the system.


* Anonymous-messages option added

The sysop or Discussion Topic moderator can now specify that
messages written in a particular Discussion Topic can be
"anonymous".  If the "anonymous option" is enabled, then each time
a user composes and saves a message, he or she will be asked
if the system should mark the note as being "anonymous" (i.e., the
user's name will not be associated with the message).  When users
read anonymous messages, instead of seeing the name of the user
in the message header, they will see the word "anonymous"
instead.  (This implies, of course, that in Version 4.0 of COCONET,
the user name "anonymous" cannot be used.)


* Text search (subject and full-text) options added

One of the most powerful features added to Version 4.0 of
COCONET is the new option to search for the occurrence of
particular word or phrase anywhere inside a Discussion Topic.


* Message author name search option added



In addition to searching within messages themselves, it is possible
in Version 4.0 of COCONET to search for a particular word or
phrase occurring within the "subject" or "title" of any message.


* Now uses an improved text editor for both text and Access Program users

In order to eliminate the 25-line-per-message limit that was present
in all earlier versions of COCONET, it was necessary to completely
re-write the editor in the COCONET Access Program as well as the
text editor for non-graphics users.  These new editors are capable
of working with messages of up to 64Kbytes in size.


* Option added to "get info" on a user when reading his/her messages

In COCONET Version 4.0 users can, while reading Discussion
Topic messages, call up the UserBase data record information on
any other user to find out who they are, etc.  (This assumes that
the sysop has allowed UserBase access to users).


* System automatically remembers what messages each user has read

Another long-requested option finally making its debut as a


COCONET feature is the new ability for COCONET to automatically
record what Notes and Responses each user has read in each
Discussion Topic.  This means that whenever other users add new
Notes or Responses, they will be considered "unread" by
COCONET and the user will be able to see just a list of "what's
new".  This feature supersedes the older COCONET HOST Version
3.2 feature whereby a user could search for all messages
composed "since" a certain date.  (The "since date" scanning
option will still be available, but will probably not be as often used
given the new automatic record-keeping feature in Version 4.0).


* Users can set all or some messages as having already been read

Sometimes it is useful for users to be able to tell the system that
they would like all or some messages considered "read" even
though they may be in fact "unread".  With Version 4.0 of
COCONET, users are able to do this.  At any time a user can
specify what messages have been "read" as of a specified date
and time.  This also means that it will be possible to tell the system
to consider some messages as being "unread" now, even though
you may have indeed read all or some of them.


* Users can elect to "ignore" certain Notes and "recall" them later



Sometimes users wish to "ignore" certain conversations that
concern issues or subject matter that are not of interest.  With
Version 4.0 of COCONET, users can do just that.  Any number of
Notes inside Discussion Topics can be marked as being "ignored". 
This means that whenever the user is scanning for new, unread
messages, the system will bypass "ignored" Notes even if they
contain unread, new Responses.  The user can, if he or she
wishes, list only their "ignored" Notes, and "recall" one or more of
them at any time if they wish.


* Moderators can now "freeze" a Note to prevent further responses to it

Sometimes it is useful for a Discussion Topic moderator to "freeze"
a certain Note, in effect, making it "read-only", so that no-one can
respond to it anymore.  This can be useful for issues that are
resolved and for issues that are now obsolete or not of interest.  It
is also useful in terms of controlling the flow of conversation and by
forcing new Notes to be written if the issue is still of interest to the
participants in the Discussion Topic.


* Moderators can now "censor" a message

Sometimes it is necessary for an inappropriate message to be
"censored" by the Discussion Topic moderator.  With Version 4.0
of COCONET, such an option exists.  "Censored" messages are
essentially "hidden" from all users except sysops and moderators. 
A sysop or moderator at any time can "undo" the "censoring", at
which time the message will again be seen by users.  Or, if
appropriate, the censored message can be deleted outright.


* Moderators can now specify "expiration dates" for old messages

Another way to keep conversations from becoming stagnant, as
well as to keep disk space from getting too limited, is to have the
system automatically "purge" Notes that have not been responded
to in a long period of time.  The time period can be specified by
the sysop or the Discussion Topic moderator.


* Authors of messages can "hide" their messages if desired

With Version 4.0 of COCONET, it is possible for the author of any
message to "hide" the message so that it does not initially appear
when another user encounters the message display.  What the
user will see instead is simply the message's header information
along with a information alert box informing the user that this


message is "hidden".  If the user wishes to "see" the hidden
message, he or she can select "See Hidden Message" off of the
"Read" menu on the menubar.  A common use of the "hide" option
is for preventing fellow users from having to read a lengthy
message involuntarily.


* Authors of messages can "withdraw" messages they wrote in the past

Sometimes a user may compose a Note or respond to an existing
Note and then decide at a later date that the message should not
have been  written in the first place.  With Version 4.0 of
COCONET, it is possible for authors of Notes and Responses to
"withdraw" their message at any time in the future.  Once a
message is "withdrawn", it is effectively removed from the
Discussion Topic, unless a sysop specifically "returns" the message
for some reason. 


* Messages can now have "attachments" (files, etc.)

Beginning with Version 4.0 of COCONET, users can "attach"
additional files to messages in the Discussion Topics.  These
"attachments" can either be additional text files, graphics images,
audio files, or binary or program files.



* External programs can now be run upon entering (and/or exiting) any Topic

With Version 3.2 of COCONET, it was possible to optionally assign
a specific CocoTalk external program to a Discussion such that any
time a user "entered" that Discussion, the external program was
run.  The most frequent reason for using such a feature was to
display a special "welcome" or "title page" message.  With Version
4.0 of COCONET, it is now possible to assign not only CocoTalk
external programs for Topics, such that whenever a user enters a
Topic that has a program assigned to it, it runs, but also upon
exiting that Topic, a program can be specified to run (often
functioning as a "Goodbye" or "Thanks for visiting, come back
again soon" display).  This is also the case with the Discussion
level: the sysop can specify a certain program to run whenever a
user exits from a Discussion.


* Now uses industry-standard RFC-822 and -1036 formats for message files

Beginning with Version 4.0 of COCONET, Discussion Topics, like
Personal  Mail, use the Internet standard RFC-822 and RFC-1036
file formats for  messages.  Coconut has added its own extensions
to the headers, in compliance with the RFC standards.  No longer


will Discussion Topic message files be stored in a nonstandard,
proprietary format. 


* Now uses industry-standard .DBF and .MDX formats for data files

For recordkeeping and indexing, Discussion Topics now use the
industry-standard dBase-style data and index files.  The fields and
records are documented in the new reference manual
accompanying the CocoTalk API C Library Version 2.0. 


* Now written as an external program module with CocoTalk API

Like other modules in this new "modular" COCONET, with Version
4.0, the Discussion Topics are run from a separate external
program that  was written using Version 2.0 of the CocoTalk API C
Library.  The new external program is called DISC.



Meetings
--------

* Up to 999 separate meeting areas can be created

Many customers of Version 3.2 and earlier versions of the
COCONET HOST suggested that only being able to offer ten
different "meeting places" was too limiting.  With COCONET Version
4.0, the limit is raised to 999 meeting places.


* Sysops can designate "meeting moderators"

Much like moderators in the Discussion Topics, "meeting
moderators", a new feature included in COCONET Version 4.0, are
users who can restrict access to certain meeting places, as well as
moderate meetings that are now occurring.


* Moderators can export "meeting minutes" files into Discussion Topics

Another new feature added to Version 4.0 of COCONET is the
ability for meeting moderators to export the captured text of a
meeting into a  Discussion Topic Note or even as a text file for the
File Exchange.


* Ability to "scroll" added for COCONET Access Program users



One limitation in the older version of the COCONET Access
Program was an inability to "scroll back" to see all of the text of a
meeting as it progressed.  With Version 4.0 of COCONET, the new
Access Program will have such an option.


* VT100 terminal emulation support added for non-graphics users

Beginning with Version 4.0 of COCONET, text-only users, i.e., users
who are signed onto COCONET via a conventional terminal
communications software program instead of using the COCONET
Access Program, will be able to participate in meetings if their
terminal software supports VT100 or ANSI terminal emulation.  This
capability was lacking in older versions of the COCONET HOST
program.  With Version 4.0, text-based users no longer need feel
"left out." 


* Options added to allow for restricting access to each meeting place

With Version 4.0 of COCONET, each of the up to 999 Meeting
Places have their own Access List.  Meeting moderators can
inspect or modify user names or Access Groups in these Access
Lists, thus being able to control who has access to what Meeting Place.




* Now uses industry-standard .DBF and .MDX file formats

For recordkeeping and indexing, COCONET Meetings now use the
industry-standard dBase-style data and index files.  The fields and
records are documented in the new reference manual
accompanying the CocoTalk API C Library Version 2.0.



CocoLex(tm) multi-language lexicons
-----------------------------------

* Sysop can create up to 99 "lexicons"

CocoLex is a major new capability available in Version 4.0 of
COCONET.  Now it is possible for the sysop to create up to 99
different "lexicons" containing words, phrases, error messages, etc.,
that should appear throughout the  COCONET system.  Thus, a
sysop can create multi-language versions of menus, error
messages, etc.  Each lexicon can be assigned its own name. 
When a user signs on for the first time he or she will be given the
option to select which lexicon to use.  Users can later change the
lexicon selection from a new option on their Personal Preferences menu.



* COCONET comes with built-in standard English lexicon as default

Coconut will ship Version 4.0 of COCONET with a built-in standard
English lexicon.  This is lexicon number 0, the default lexicon.  The
sysop can then add lexicons 1 through 99.


* All built-in error messages and on-screen instructions now use CocoLex

Beginning with Version 4.0 of COCONET, the HOST program as
well as all of the standard modules will use CocoLex for error
messages, on-screen instructions such as "Press ESC to exit", etc.



List of users online
--------------------

* Sysops can now specify how much information users will see

In Versions 3.2 and older of the COCONET HOST program, when
a user indicated that they wanted to see the list of users currently
signed on, they simply  saw a list of user names.  Many customers
have asked us to add options so that users can see additional


information about who is on, where they are calling from, and what
they are doing.  Beginning with Version 4.0 of COCONET, the
sysop will be able to specify how much information is available to
the user when they invoke the "List Current Users" option.  At its
most detailed level, users will see the names of users, the city and
state/province that they are located in, and the type of "activity"
(chatting, reading mail, composing a Discussion Topic Note, etc.)
they are currently engaged in.


* Users can now select a user's name on list for chatting

Beginning with Version 4.0 of COCONET, users will be able to
select user names directly from the "List of Current Users" to page
them for chatting. Prior to Version 4.0, it was necessary to first look
at the list, then select the "Personal" menu, then the "Chat" menu
item, then type in the name of the user that they had seen listed on
the list a moment ago.  Now those extra steps are eliminated,
making it easier than ever to chat with other users.


* Users can now select a user's name to call up their UserBase record

Another new feature included in the List of Current Users is the
option to "get info" on any user whose name appears in the list. 



When this option is selected, the user's UserBase record is called
and displayed (assuming that the enquiring user has proper
access to UserBase).


* Users can "hide" themselves if sysop has allowed such an option

The sysop can now specify whether no-one, sysops-only, or all
users can optionally "unlist" themselves from the "List of users
online" while they are signed on.  Some sysops may only wish
themselves to have this option, whereas other sysops see no
reason to deny this kind of privacy option from all users.  With
COCONET Version 4.0, the sysop will have several ways to
implement this new feature.



Enhancements to COCONET Access Program for DOS
----------------------------------------------

* Memory Support

Now uses extended or expanded or virtual memory if available

Previous versions of the COCONET Access Program for DOS


(CAP/DOS) primarily used the standard 640K region of DOS
memory, which meant that memory was often in very short supply,
since the COCONET.EXE program itself consumed so much
memory just to run.  The new version of CAP/DOS detects and
uses extended or expanded memory for many more internal
operations.  This frees up more of the 640K RAM region for other
DOS programs and drivers.  If neither extended nor expanded
memory is available, the CAP/DOS will create virtual memory areas
as disk files if there is not enough room in the 640K RAM region.

* Video Display Support

* SuperVGA (640x480, 800x600, 1024x768) 256-color support added

The new CAP/DOS supports many additional video display modes,
including three important new 256-color modes: 640x480 pixels,
800x600 pixels, and 1024x768 pixels.


* Most VESA drivers added

In addition to the SuperVGA modes described above, the new
CAP/DOS also supports a variety of the VESA video modes that


have been recently introduced in the industry.



> Bitmap Graphic Image Support
* (8-bit) 256-color PCX support added

One tremendously powerful new feature of the new CAP/DOS is
the support for 256-color 8-bit PCX bitmap images.  These images
offer much more photographic realism.


* Dithering capability now allows 256-color images dithered on
  16-color and 2-color displays

A perennial problem with older versions of the CAP/DOS was the
fact that if the user's PC had a Hercules monochrome graphics
board, it was not possible to correctly display color PCX images. 
With the new CAP/DOS, a dithering capability has been added,
which makes it possible to see even 256-color and 16-color images
on a monochrome display, as black-and-white images.  Also, users
of conventional 16-color EGA and VGA monitors will be able to see
a 256-color image dithered into 16 colors.




* If CocoMedia option available on system that user is connected to,
  JPEG image files can be decompressed and displayed on screen

Due to the increased file size (and therefore file transfer time) of
256-color PCX images, it was necessary to find a way to compress
the images so that it would be practical to send them over modem
connections.  Coconut has chosen the industry-standard JPEG
compression algorithm for solving this problem.  The JPEG support
is available through a new add-on product called CocoMedia.  Only
COCONET systems that have a licensed copy of CocoMedia
installed will be able to make use of the JPEG compression capability.


> Text font support

* Fonts improved to better serve higher-resolution VGA displays

With the new support for higher-resolution video modes, it became
clear that new fonts were needed so that text would be readable
in the new video modes.  Beginning with Version 4.0 of COCONET,
the CAP/DOS contains a new set of text fonts designed to work
with all of the supported video modes.


> Audio support



* If CocoMedia option available on system that user is connected to,
  Access Program can play audio files through PC audio board
A powerful new capability added to the CAP/DOS is its support for
playing audio files through an audio device.  This capability will be
available on COCONET systems that have a licensed copy of the
new CocoMedia add-on software product installed.  Initially,
CocoMedia supports Creative Labs' Sound Blaster audio boards
for PC's.  In the future, Coconut plans support for additional audio
boards and devices.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

For More Information, Contact:

Coconut Computing, Inc.
7946 Ivanhoe Avenue, Suite 303
La Jolla, California  92037
Voice: (619) 456-2002
FAX: (619) 456-1905
E-mail: info@coconut.com


COCONET is a registered trademark and Coconut, the Coconut


logo, UserBase, CocoTalk, CocoLex, and CocoMedia are
trademarks of Coconut Computing, Inc.  Apple and Macintosh are
registered trademarks of Apple Computer, Inc.  Sound Blaster is a
registered trademark of Creative Labs, Inc.  SCO is a registered
trademark of Santa Cruz Operation.  UNIX is a registered
trademark of AT&T.

Copyright 1992 Coconut Computing, Inc.

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

-- 
Ken Germann              ZZZZ EEEE  OO   SSS    ZEOS International, Ltd.  
support@zeos.com   INET     Z E    O  O S       Technical Support Dept.
uunet!zeos!support UUCP    Z  EE   O  O  SS     530 5th Ave N.W.
800-228-5390      VOICE   Z   E    O  O    S    St. Paul, MN 55112
612-633-7337             ZZZZ EEEE  OO  SSS     FAX         612-633-4607
Newsgroups: alt.bbs