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.