Theme II: The System Technology of Free-Nets
August 18, 2.25 - 3.15 pm

1. QUESTIONS FROM EXPERIENCE WITH A FREENET PROTOTYPE
     Walter Lewis, Halinet

This presentation described the experiences to date with the Halton
Information Network (Halinet), and the lessons learned. Halinet
partners include Sheridan College, two school boards, a number of
libraries and regional agencies and a variety of information
providers. The partners want to build a regional telecommunications
infrastructure which can be used not only to distribute information to
the public, but also for internal operational purposes. Halinet is
more than just a FreeNet, but currently it is only being used in a
closed user group mode. 

The system is currently implemented at Sheridan College on an old
Micro-Vax computer using FreePort software; as a lesson learned,
Walter stressed the need to stick to supported hardware and to have
access to committed staff with systems expertise who can carry the
implementation through to completion. Gopher, Telnet and the FreePort
Mail capablity are supported. There is one suite of newsgroups.
Newsfeeds are obtained from UPS, with Canadian content coming from
Standard Broadcasting. 

Future problems to be resolved include the integration of newsfeeds
from commercial services which have not been designed for this type of
network environment; the provision of more library services over
extended hours, with the expenditure of less staff time; and the
question of standards for data queries. There are also some general
Internet access issues, which are common to many FreeNets. 

2. UNDERSTANDING FREEPORT
     Andrew Patrick, Communications Research Centre and NCF Board

The transparencies used for this presentation have been put up on the
conference presentations board. The presentation dealt with the use of
the FreePort systems software at the National Capital FreeNet (NCF).
It outlined the system design objectives and history of FreePort
software development ("many hands over several years"), provided an
overview of the 8 main systems which perform the different functions
(see transparencies), described limitations encountered and the main
lessons learned at the NCF, and outlined criteria for developing and
adding new modules. Andrew stressed the need to be careful of
tradeoffs between functionality and ease of use; between the needs of
novices and power users. One should be prepared for a heavy load early
after launch, rather than a steady growth; looking back with
hindsight, perhaps an automatic registration system should have been
implemented from the start.

Finally, Andrew described directions for future work. These include
multilingual support, which will require and can be used to justify a
major reworking of the software, and the implementation of client-
server models which take advantage of much greater processing power at
the user's end, but will require the development of some de facto
standards. Finally, the question of software for broadcast systems,
which provide 1 1/2 way interaction (i.e. the downlink has to have a
much greater bandwidth than the uplink) was discussed.


3. MAKING THE NATIONAL CAPITAL FREENET BILINGUAL
     Peter Hickey, University of Ottawa

To emphasize the importance and need for supporting more than just the
ASCII character set, Peter pointed out that dropping diacritics in
French would amount to asking users to work with an alphabet missing
20% of its characters. It would be like saying "why worry about it?"
if you were trying to give someone a really good deal on a
telephone... with the 7 and the 3 missing.  Saying something like "But
it's a great deal, even if you can't use it to call up a lot of your
friends!" would not be a very convincing sales pitch.  He gave reasons
why the ISO-8859-1 (Latin 1) international standard character set
should be used. The ideal solution would be for all users to identify
a standard character set and use translation tables to map all input
from and output to that set and Latin 1. A more practical solution
would be to ensure that each user uses the "proper" character set. If
the user's equipment is incabable of displaying the diacritics and
other characters required (impossible equipment), then he willl see
junk or nothing.

MS-DOS environments pose special problems. DOS is incompatible even
within itself. It is the responsibility of each application program to
map to and from the Latin 1 character set. Each user seems to use a
different terminal emulation package. These can be divided into three
categories: those that work well, those that can be made to work and
those that cannot be made to work. Finally, there are the problems of
going from a 7-bit to an 8-bit code. Some UNIX utilities are not 8-bit
clean; sorting does not work; and string matching may or may not work.
There is also the problem of compatibility with users in other
countries who have not gone to an 8-bit standard.
 
At the more philosophical level, there are difficult questions
regarding what is really meant by a bilingual system, which must de
discussed and hopefully resolved. Does it mean that everything,
including all content, must be duplicated in both languages? This is
clearly impossible in FreeNet environments. Is it sufficient to have a
language choice at the start of a session, with French menus appearing
as a result of the corresponding choice? Should everything be mixd
together? A possible solution is bilingual menus; another is menus in
the language of choice. The inputs provided by the IPs would have to
be left in the language in which they are provided.


SUMMARY 

There was widespread acceptance of the idea that considerable
improvements are required to FreePort, the system software most
commomly used to set up FreeNets. Future directions of improvement
include multilingual support, which can be used to undertake a major
reworking, the implementation of client-server models which take
advantage of much greater processing power at the user's end, and
software for broadcast systems.