May 22, 1997
CompuServe and Internet Integration Committee
DP Users Cooperative
Summary Of Findings
May 7th 1997
Table Of Contents
~~~~~~~~~~~~~~~~~
1. Objectives Of The Committee
2. Summary And Recommendation
3. Important Notes
4. Requirements Of The Coop EHome
5. Alternatives Evaluated
6. Acknowledgements
1. OBJECTIVES OF THE COMMITTEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The CompuServe and Internet Integration Committee (CIIC) was formed to
investigate what alternatives are available to provide an electronic
home (ehome) for the DP Users Cooperative (Coop) and to recommend which
of any alternatives found would be most suitable.
The main requirement of the ehome is to be able to provide a single
(electronic/network) location from which the Coop can operate. All Coop
members must be able to participate equally, whether accessing the ehome
from CompuServe or from the Internet.
The committee was interested in establishing what product (or products)
would support this requirement. We were not concerned with where this
product (or products) would be physically installed and operated from.
(Other than ensuring that the products evaluated were not excessively
restrictive in what platforms were supported.)
To effectively evaluate alternatives for a Coop ehome we needed to
establish a more detailed set of requirements than stated here. The
requirements that we decided were appropriate are listed in section 4.
2. SUMMARY AND RECOMMENDATION
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We were unable to commit to a single recommendation at this time. The
Efora product would appear to be the product of preference but is
insufficiently developed to make a definite recommendation.
Since we do not believe that the Coop needs to move to the recommended
ehome with particular urgency, we suggest that the time exists to permit
the efora product to be further developed and evaluated. With this in
mind...
The committee recommends that the Coop formally request Bruce Conrad
(Sanbachs) to build a prototype of his "efora" product presenting the
following functionality (within the stated requirements):
* An online interface similar to the currently available
prototype but with message listing and search capabilities.
* An offline interface (email)
* Some level of message management for authorised
members - archiving, moving messages etc
* "Information" Web pages to present data within secured
levels of the site. This should have links to FTP
to demonstrate file access.
It has been suggested (by Bruce) that he could partner with someone else
in the development of the underlying DP database for the system. Such a
development could help ensure that the message database itself is a
useful utility in its own right.
If the prototype fails to meet the satisfaction of the Coop - or members
appointed to evaluate the prototype - then this committee recommends one
of the following alternatives being implemented in its place (in order
of preference):
1. Combination of...
a. A Private News Facility for discussions
b. A "traditional" Web site for commerce
c. FTP for file access.
This solution should be reasonably inexpensive and
portable enough to fit within any host/provider limitations.
2. Lotus Domino
Should be able to provide all facilities required
(with links to FTP for file access). May have some
problems getting compatible host/provider. Offline
access requires purchase of a "Lotus Notes Client".
3. IMPORTANT NOTES
~~~~~~~~~~~~~~~~~~
The recommendation to wait for the development of the efora product
raises some important questions. We have tried to predict and answer
some of these questions here (with the help of Bruce Conrad).
* What are the copyright/ownership issues in assisting Sanbachs to
develop the underlying DP application for the efora?
When asked this, Bruce replied:
> Ideally, I'd like to see the DP Co-op own 50-51% of the
> entire efora thing, in exchange for providing the DP
> database design and the sales and marketing effort. This
> is, after all, an offshoot of DP, and has the potential,
> with effective marketing, to be a commercial success. I
> would personally be happy with my share of Sanbach's share
> of a commercial success...
* Is Bruce willing to build the prototype discussed without full
commitment from the Coop?
He is.
* How long may it take to build the efora prototype?
Bruce thinks that it would only take a matter of weeks for an efora
interface to be built over a message database. This would be a
preliminary product which would evolve as time progressed.
Obviously the actual efora development may have to wait/coincide with
the development of an appropriate message database which may add to this
estimate.
* How much will it cost the Coop to licence the final product?
This will depend upon what is decided about the joint development
options discussed.
* Is there any conflict between this development and that of the
"components" proposed by Steve Patamia?
Since both developments may provide GUI interface capability to a
"DataPerfect-like" database it is possible to see there being a conflict
or duplication here. However the efora product is NOT really a
"development product". Rather it is an application that is (will be)
custom designed and built to interface with a specific DataPerfect
database.
It is possible that the efora product could be migrated and even
expanded upon once the components become available.
Bruce sees the two developments as "complimentary" rather than
conflicting.
* What platform restrictions are there in using efora?
Online access is available with any Internet browser, offline access
should be available via any email application. The efora software
itself is written in C and has been successfully compiled to run on
"several different platforms".
4. REQUIREMENTS OF THE COOP EHOME
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The requirements listed here are still stated at a fairly high level.
This was considered sufficient for evaluating existing product
alternatives, if product development is required (the "efora"
alternative) then these requirements may have to be expanded into
greater detail.
1. Access.
~~~~~~~~~~
1.1 Provide access for all members at minimum cost.
It is assumed that all members will already have Internet and/or
CompuServe access. This requirement implies that users should be able
to access the Coop using their existing communication applications. It
may eventuate that users will want to purchase additional software to
permit advanced forms of access.
1.2 Should provide for online and offline access.
This required is to allow minimisation of connect charges while
permitting more dynamic interactions such as are already available on
the Internet.
1.3 Must provide a means of notifying members of issues requiring their
attention. This requirement can and may be fulfilled by simple broadcast
email.
2. Security.
~~~~~~~~~~~~
2.1 At least 4 levels of security required.
- Board Members and Administration (Sysop)
- Voting Membership
- All Membership (voting and associate)
- Public
The most important part of this requirement will be the ability to
secure the information held from external (non-Coop) access.
2.2 These security levels should be definable and enforceable over
discussions, message archives, file archives and any online interface.
2.3 It is desirable to have the ability to setup additional/temporary
areas from which committee groups - such as the CIIC - can operate in
privacy, with only specified members in participation.
2.4 Facilities must be provided to enable backup of the information
held and off-site (secure) storage of such backups.
2.5 Members may need to be encouraged to store any discussion and file
data that they download in a secure environment - or - rely upon the
Coop to provide the secure environment and encouraged not to maintain
their own archives.
2.6 The service must be able to be held in a secure environment, either
under direct control of the Coop or with a trusted host.
3. Discussion Management.
~~~~~~~~~~~~~~~~~~~~~~~~~
3.1 The service should provide versatile and flexible discussion
management tools. Including at a minimum:
* Threaded discussions
* Ready access to messages that have not been read
* Archiving
* Versatile search capability
3.2 It is desirable, although not probably not essential considering the
probably low volume of data, that the service also provide:
* Movement of messages/threads from one area to another
* Allow messages to be addressed to "All"
(All participants must receive the message)
* Allow messages to be addressed to "Anyone"
(To no-one in particular, just anyone with the time
and/or knowledge to answer.)
* Track whether messages have been responded to or not
* Permit the use of "News" messages which remain available
to all new members to the discussion (are not
automatically archived like other messages).
4. File Management.
~~~~~~~~~~~~~~~~~~~
4.1 Support the ability for members to upload and download files to
authorised areas.
5. Commerce.
~~~~~~~~~~~~
5.1 The server/host should provide, or be able to provide when it
becomes necessary for commercial access requirements. For example;
advertising Coop products and perhaps paid banner advertisements from
other companies (to help support the site).
5. ALTERNATIVES EVALUATED
~~~~~~~~~~~~~~~~~~~~~~~~~
The following details the alternatives which were evaluated and why each
alternative was discarded (or otherwise). CompuServe was not considered
as an alternative for reasons which have already been widely discussed
in open conversations outside this committee (primarily problems with
copyright and access by Internet members).
A. Manual System
~~~~~~~~~~~~~~~~
Coop discussions could be operated via simple email mailing lists. Each
member would maintain a list of other members and discussions would be
held by each member addressing their correspondence using this list.
Has the advantage of simplicity and the fact that most members will
already have products which they use that are capable of supporting
this. However there could be difficulties ensuring that each member's
list is accurately maintained and there still remains the problem of
message management - one or more members would need to maintain
appropriate archives etc.
This item was not considered in any great detail. This method was how
this committee was operated and is seen as an alternative of "last
resort" if no other alternatives offer what is required. It may still
be that this alternative could supplement any shortcomings of the other
alternatives considered if necessary.
B. ListServer
~~~~~~~~~~~~~
The Coop could implement 3 or 4 listserver lists. Each relating to the
different levels of Coop involvement - board, voting, all, public?
This alternative was considered as having some potential when combined
with FTP and Web page facilities. It was eventually discarded since
other alternatives offered better message management and automation
features.
C. EFora (Sanbachs)
~~~~~~~~~~~~~~~~~~~
Further development of the Efora product demonstrated by Bruce Conrad
(Sanbachs) could provide both the online and offline discussion
facilities needed.
Since the database over which the Efora operates is a DataPerfect
database, many useful possibilities present themselves. The database
could be built and maintained using Coop expertise and the application
could be available to other members as deemed appropriate.
This product is seen as potentially the best of the alternatives listed.
Refer to the "Summary And Recommendation" and "Important Notes" sections
for details.
D. Web-Base
~~~~~~~~~~~
The use of DP to create HTML, as demonstrated by Mike Sharp, could
conceivably be expanded to support some of the listed requirements.
This alternative was excluded on the grounds that it would not
conveniently support offline access.
E. Telnet BBS
~~~~~~~~~~~~~
It is possible to operate a BBS system which is connected to the
Internet using Telnet. Members could dial into the BBS if local to its
physical location, or use Telnet facilities to access the BBS via the
Internet (including via the CompuServe-Internet connection).
One of the main difficulties here appears to be that this alternative
would *require* some hardware investment AS WELL AS the services of a
trusted ISP. This does not offer the same level of flexibility as other
alternatives which could be hosted with a trusted ISP *or* our own
hardware.
F. Javascript or other HTML related programming
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A custom built Web application could be built to provide some or all of
the functionality required using Java or other HTML related programming
tools.
Like the "Web-Base" alternative this has been excluded on the grounds
that all of the systems demonstrated require online access which is
inappropriate for CompuServe member access.
G. Domino (Lotus)
~~~~~~~~~~~~~~~~~
Lotus has expanded its "Notes" product to include some substantial Web
features via a product set it refers to as "Domino". These tools can
provide security and discussion management as well as general Web page
and other facilities using a Lotus Notes Server as its base.
This has been listed as the last of the recommended solutions. The full
cost of installation is likely to be significant and offline access
would require that members have a "Notes Client" software package. On
the positive side, both the server and the client software are available
over a wide range of platforms and it would appear to be a very flexible
and powerful solution.
H. Private NEWS
~~~~~~~~~~~~~~~
It is possible to setup an Internet NEWS server which is not part of the
"USENET" news network. Such a system would implement a threaded
discussion facility with automatic archiving and other message
management. Various shareware and freeware applications are available
for accessing these system, even via CompuServe's Internet connection.
This system combined with FTP and Web page services could be implemented
to meet the stated requirements. Implementation costs should be
relatively low. This has been listed as the second of the recommended
solutions, an attractive option should the "Efora" alternative not
progress as desired.
6. ACKNOWLEDGEMENTS
~~~~~~~~~~~~~~~~~~~
The committee members were:
Geoff Worboys - Chairperson
Ralph Alvy
Mike Sharp
Jim Baltaxe (primarily as an observer)
Bruce Conrad provided significant input concerning the "efora" product.