 |
 |
 |
 |
 |
 |
 | |||
 |
 |
 |
 |
 |
|
|
|||
, 
, up
, Title
In this section practical approaches to the use of the Web for CBL delivery are examined by looking at different possibilities using the technology. The first of these examples is a fairly simplistic approach, which does not satisfy all the desirable security and efficiency aims but serves to illustrate the possible mechanisms available. Next systems that can be found in use among other projects are considered, in particular the BioNet and Interact TLTP projects already mentioned above ([4] and [7]). For further details of these contact can be made with the appropriate projects and authors.
The final case considered is the pilot study construction of a server within the Institute for Computer Based Learning to meet the needs of the Learning Technology Dissemination Initiative (LTDI). This pilot study led to a set of prioritised requirements for a server and the construction of an initial set of tools to start to meet these needs.
5.2. Information required for each item
If CBL material is to be usefully supplied from a server it needs to be organised and presented in a consistent way. Items that should be supplied could include:
Figure 1: An example page for serving CBL programs
In this example the items shown underlined are exploiting the linking capabilities of the Web to connect to further information stored about the author, the project, etc. Selecting the links to the chosen version starts a file transfer to deliver the material to the client machines. Depending on the type of the file this could start running immediately or be installed and executed separately.
This is shown here simply as an example of what is possible. However it would be possible to build up a useful collection based on delivery for local installation without any changes to servers or clients.
Using mime types to launch programs
The default action for unrecognised file types in most WWW clients is to transfer the files to the local machine. It is then left to the user to install the package in the appropriate way. This is similar to the process that needs to be undertaken when transferring files from ftp sites. The action that is taken by the client can be altered depending on the mime-type of the file. This is most easily controlled using the suffix on the file. For example the commonly used PC archiver and compression utility PKZIP uses .zip as a file extension. On the server this is mapped to a mime-type in one of the server configuration files (mime.types for the NCSA server) using a line of the form:
application/zip zipThis associates the ending .zip with mime-type application/zip, the client then associates this mime-type with a program available on the client machine, e.g.
application/zip= c:\utils\pkunzip %lsThe %s indicates that the file passed from the server should be passed as an argument to the program. (Note the exact form and location of these entries varies with the client or server and the platform).
To deliver CBL material the types can be extended to include suffixes associated with known types of authored CBL. For example CBL produced for PC compatibles is often authored using Authorware Professional or Toolbook. In either case these packages are normally executed using a run-time engine based on the client machine. Under the assumption of local availability of these run-time engines a package could be delivered and launched direct from a page of the World-Wide Web by making the following mime associations:
On the server:
application/x-authorware app application/x-toolbook tbkOn the client:
application/x-authorware= c:\apw2\runapw2.exe %ls application/x-toolbook= c:\toolbook\tbook.exe %lsThe use of an x before the mime description signifies an experimental mime type as distinct from those registered and widely used.
Limitations of this approach are that the package is always transferred from the server even if transfer has already just taken place, there is a dependency on the run-time components, and new mime types are needed for each different authoring package.
A further problem can also be identified when this is applied to Apple Macintosh machines. A Macintosh file consists of three parts, the data fork, the resource fork and the file information. When a file is transferred between platforms the special structure is lost unless preserved by encoding the file. As a result any file where the information in the resource fork is needed cannot be associated directly with its run-time component, or immediately executed if it is self contained.
Interpreting instructions from the server
The limitations of associating different file types with their run-time engines one possibility is to use an interpreter on the client to carry out a series of instructions delivered from the server. This can be most easily illustrated with reference to the Unix server and client. One of the default mime types recognised by the Unix WWW server is the shell command interpreter sh.
Files ending .sh are mapped as:
application/x-sh shOn the Unix client this is enabled by entering in the .mailcap file
application/x-sh; sh %sSequences of shell commands can be stored on the server and executed on the client by selecting the appropriate link. For example (see figure 2)if foo.sh contains
echo "Your home directory is " cd pwdthis can be referenced inside an HTML document as
<a href="foo.sh"> select this to see your home directory</a>Figure 2: Example using the shell to execute code from the server on the client
Using the shell as interpreter allows all forms of command to be processed including file transfers, copying, deleting, and program launching. This demonstrates that a sufficiently powerful interpreter is available to meet the need for installation and launching of packages. However it is too insecure, enabling general interpretation of shell scripts would allow, for example, the script
cd / ; rm -rf *which attempts to delete all files from the client system!
An interpreter more limited in ability but capable of meeting the requirements for transfer and installation is therefore needed. It is possible that a general interpreter such as safe-tcl a restricted version of tcl[19], which is deliberately limited in scope may be suitable, but the installation process does involve some file operations which are unlikely to be available in a system that is both general and secure.
A specialised interpreter can be constructed in any language, for the trial system perl[20] was selected. This is suitable because it possesses powerful text and file handling capabilities and it has an associated library for working with Web services. In particular a "url'get" construct exists in the library allowing a perl script to access any file stored and referenced on the Web.
Package_nameAn example file on the server might contain:
Version
Remote_location
Local_directory Launch_command
Package_name=Test Version=1.1 Remote_location=http://www.icbl.hw.ac.uk/patrick/testprog Remote_location=http://www.icbl.hw.ac.uk/patrick/test.data Local_directory=testdir Launch_command=testprog test.dataThe result of selecting this file is then to install testprog and its data file test.data in a subdirectory of the designated install area and then run the programme on the client machine. The installation can then be recorded locally so that if the same package and version is required a second time only new files from the remote server are transferred and the launch command carried out. In particular if exactly the same process is rerun only the command script is transferred across the network.
For the example the command files are stored with the suffix .cbl and the a new mime type defined on the server as:
application/x-cbldownloader cblOn the client the entry associated this mime type with the interpreter written in perl:
application/x-cbldownloader; download.pl %sNo further mime types then need to be defined.
The creation of the .cbl structured file can be assisted by using WWW form facility available in most clients. The form shown in figure 3 is completed to specify the information required. This form contacts a program running on the server to return the correctly formatted data to be stored in the .cbl file. This ensures that the lines needed in the interpreted file are correctly constructed. This use of forms can also be extended to centrally store the download instructions in a collection for dissemination.
Figure 3: A form to help construct download descriptions
Developing the interpreter for other platforms
This example has shown that with no additional features it is possible to deliver material, however it quickly becomes desirable to have a special downloading process. A possible approach using a download interpreter has been described. The version defined here would need further development to address all security issues and all needs of the download process.
The example interpreter runs successfully on Unix platforms but there are potential problems in generalising it for other platforms. In particular for PC programs this type of interpreter might most simply be constructed as a batch process or in the PC version of perl. However the majority of PC CBL programs run under Windows. This means that it is necessary to launch the Windows program from DOS, this can be done by using client-server programs available for the PC but it does introduce a further level of complexity. An alternative is to program the interpreter to run under Windows by using other development languages.
5.3. W3launch - a World-Wide Web launch program
The BioNet project funded under TLTP has identified and encouraged a wide range of CBL packages related to Biology and Biological Sciences. The main aim of the project has been the introduction of these into teaching at many Universities. As a part of this the project has made use of WWW and ftp servers to disseminate the programs.
Some of the packages have description pages set up as "student pages" as in figure 4. From these pages students can make selections and run programs already installed on their local machines. In this example the description includes text and still graphics, and if the student is given the option of running an animation if it has already been installed on the client machine.
Figure 4: Example student page for use with W3launch
The W3launch program created by John Maber[7] acts as the interpreter to establish which program should be run on the client. The interpreter use the suffix .w3l and the mime type application/x-w3launch to communicate from the server to the client.
A version of the program is available for Unix machines and for PC compatibles. The PC version has been developed more fully and allows local editing of the behaviour in addition it is constructed to run under Windows to allow the easy launch of other Windows programs.
This package does not attempt to automate the installation process, so avoiding the security problems inherent in transferring programs, but has developed a mechanism to allow the use of programs described on remote Web servers.
5.4. The Interact Communication Facility
The Interact TLTP consortium is developing simulation software for use by those teaching Engineering subjects. As a design decision the target platform is Unix workstations running the X Windows system. This decision was made to provide a platform powerful enough form the simulations to run smoothly, however it also means that the developers have been able to take advantage of the multi-tasking and communication facilities within Unix.
One aim if the Interact consortium was the provision of on line guidance to users. This was achieved by writing hypertext delivered via WWW and Mosaic. However it then became necessary to integrate the tutorial descriptions with the simulation software. For this reason a means of communication from the information presented on the Web and the simulation programs was developed. The resulting Interact Communication Facility (ICF) provides a language to communicate from the server with the simulation programs running on the client machines. The project was not seeking to automate the install process but as both the client simulations were being constructed by the same team they were able to add two way communication.
Figure 5: A student page for use with Interact simulations
The programs using ICF can not only be launched by selecting items on the Web but also controlled once they are running. This allows the programs to be placed in particular example states (see figure ) and then the student can observe and report on the results of the simulation. In addition the specially written simulations can save their states in a way that can be passed back over the web. This encourages the sharing of results and makes it easy for a tutor to save interesting states in the simulations. The Interact team plan to take further advantage of this facility by developing a version of the Answer Garden[8] concept so that when questions are asked the answer can include the necessary state for the student to see a particular point the tutor might wish to make.
5.5. Establishing a courseware server for LTDI - a pilot study
Background to the LTDI project
The Learning Technology Dissemination Initiative is a programme supported by the Scottish Higher Education Funding Council with the aim of encouraging take up of computer based learning methods within Scottish Higher Education Institutions. To achieve this the LTDI team is organising workshops around Scotland and arranging visits by members of the team to individuals and Departments to demonstrate and promote the possibilities in particular subject areas.
As a part of this programme a collection of CBL material is being gathered from various sources both commercial and from other initiatives such as those funded under TLTP. This collection needs to be organised so that those on the LTDI team can easily select items for demonstrations.
Within LTDI the World Wide Web is being used to promote the workshops and provide information about the project. The existing use of the Web and the large collection of software were reasons for selecting LTDI as a pilot for some of the ideas and requirements outline in the earlier sections of this report. In collaboration with members of the LTDI team specific requirements for their needs were identified and an initial set of tools constructed to meet some of their needs. This work is continuing and it is intended that the majority of the collection will be organised and distributed for demonstration using the World-Wide Web.
The LTDI programme has the specific need to demonstrate a wide range of software though workshops and visits by team members. The requirements that they have in particular were established through an interview and discussion about the possibilities. The requirement list produced is given in table 1 below
Requirement Priority
1 To be able to put demonstration machines into a known state High
2 Access to all types of PC software (Windows, DOS, run-time High
dependent)
3 Ability to remove previously installed software High
4 Integration of downloads with a database of software High
5 Ease of access to place material on the server High
6 No unnecessary transfers of previously installed components High
7 Customisation of installs to allow partial installation of High
multi-part packages
8 Security High
9 Access to software for non-PC platforms (Macintoshes and Unix) Medium
10 Demonstrations available over the web without local installation Medium
11 Links and compatibility with other sites addressing software Medium
distribution
12 Access to information and programs from CDRoms Medium
13 Running and customisation of programs by selection from the server Medium
14 Comments and illustrations on the programs available Medium
15 Browse software to download to hard disk Low
16 Easy contact with the maintainers and authors Low
Table 1: Requirement for the LTDI courseware server
The requirements specified for the LTDI server vary in importance and in the difficulty in which they could be met using a remote server. The overall requirements from LTDI also reflect the need for installation to demonstrate to others rather than to deliver to the whole community over the net. In this case the users of the dissemination system are likely to limited initially to members of the LTDI team and the server is constructed to not be visible outside of the host institution.
Some of the requirements, for example to return to a known state, to be able to remover software and to be able to avoid unnecessary downloading of code, imply that a record needs to be kept of the state of the machine that is receiving the software. The need to browse and select software and to vary the configuration of packages before they are downloaded, imply interaction with the server and querying of data stored about each program. As the programs will not have been constructed with this form of installation in mind the information needed for installation remotely also needs to be gathered.
At this stage there is no requirement for wide accessibility so that solutions based on local area network technology could be considered, however much of the software gathered can be freely redistributed so that a wide area distribution will be required in the future. The World Wide Web technology therefore could offer a solution to current problems and in the future allow much wider access. The initial target machines are PC compatibles reflecting the greater volume of software being produced for those platforms and also the greater need for special installation procedures, particularly for programs running under Microsoft Windows.
The solution suggested consists of the following elements
1. An installation monitoring program: This is used by the person who is to install software onto the server. As a first stage the software is installed on to one of the target machines and the monitoring program reports all changes caused by the installation. This record can then be used for subsequent installations and for returning the machine to the state it was in before the software was installed.
2. An installation database: This records the packages installed and any dependencies between the package and other programs or run time routines.
3. An installer client: This receives information from the server and interprets the instructions in that information to fetch and install the parts of the software.
4. Installation pages: Based on the server these pages describe the software and how it can be transferred to the client.
5. Server utilities: On the server there needs to be a database of the software and background information such as contact details.
The installation monitor uses a stored state of the target machine and a perl script to do a comparison of all files likely to be changed. This could be all files and directories on the machine but in practice it is found that the time consuming comparison of all files can be replaced by an analysis of those in particular directories only. For example, Windows files need to be monitored but not those related to networks or the basic DOS operating system. The different files installed are stored in a list indicating if a new file is installed or if changes have occurred in text files (such as WIN.INI) the exact lines changed are recorded.
The installer uses the files installed during the monitored installation process and the comparison of states to automate the installation. In this case the installer instructions are passed to an interpreter on the client which copies the new files and makes any necessary changes to existing files. For the pilot version of this tool the transfer is made using the local network (PCNFS) rather than the Web. It would be possible to construct a system similar to that designed around the url'get construct described above. However this would need the appropriate function to be created for the PC platform and is not required to meet the direct requirements for the LTDI pilot. This is however a very important extension if the program can be used in more general circumstances.
The installation pages are constructed from the monitored installation process. These need to be developed to allow the user to specify the part of the material to download. The Form interface within the WWW clients is a suitable way for this to be specified, the download script then being tailored to the specifications given by the user. An existing database of software can also be transferred across for delivery over the Web by building pages dynamically from the information in the database, this information then integrating with the download process.
The software to meet the requirements of the LTDI team is under development. The experience of the LTDI team has revealed that installation and removal of software is not a straightforward process, particularly when under MS Windows. The automation of this process by monitoring and recording of actions should enable subsequent installations to proceed more easily. These tools will initially help with management of the local area network but by building them in conjunction with the technology of the Web they can be extended to allow complex installations to take place over wide area networks.
,
, up
, Title
Graphics Multimedia Virtual Environments Visualisation Contents