                       FUNCTIONAL SPECIFICATION REVIEW


Topic:   Black Support for Network-only Kryten Functional Specification
           (Issue F - 6th September 1994)
            
Date:    8th/9th September 1994

Present: Martin Clemoes        (project manager, author)
         Martin Neville-Smith  (author)
         Jonathan Coxhead      (author)
         Mike Hardy            (reviewer)
         Neil Gardner          (reviewer)
         Carl Sellers          (reviewer)
         Charles Whyte         (reviewer)
         Alastair McGregor     (8th Sept only)
         Mike Challis          (chairman)



1  Scope


This specification covers the changes to RISC OS required to support booting
from a network fileserver (rather than from a local hard disc).

The primary objective is to make sure that Kryten platforms without hard
discs can be installed as part of a network: installation, configuration and
user booting are all designed to be as user-friendly as possible. The
secondary objective is to provide a network boot solution that will work
for a network of mixed platforms, including machines running earlier versions
of RISC OS and machines with hard discs.



2  Major issue


2.1  Timescale

Although no single issue can be isolated as a "major" issue, the review
uncovered a fair number of issues which ideally require further discussion
amongst interested parties before freezing the specification; examples of
such issues are treatment of CMOS settings, creation of a single Boot entity,
and support for third party fileservers.

Unfortunately this work is now on the critical path of the Black project
plan, and there may not be enough time left to deal with all of the issues as
thoroughly as would normally be the case; this means that there must be some
risk that design decisions taken now are sub-optimal.

To try to minimise this risk, we recommend that the revised specification be
copied to all reviewers as soon as it is completed so that at least one
further check on consistency is made before release.



3  Other issues


3.1:  Although not strictly a deliverable of this project, the proposals
should be designed to work on network-only RISC PC's as well as Krytens.

3.2:  The interaction of network booting with hard disc booting should be
considered.

3.3:  The integration of ArmBoot, ShareBoot and Boot into a single boot
entity would, if possible, be a worthwhile simplification.

3.4:  A Network Manager's manual should be considered as a separate book to
be included with the Network Setup Application Suite floppy disc set. It's
probably better if these items are made a product in their own right, rather
than being bundled with every network-only Kryten.

3.5:  Clarify meaning of "Level 4 network" (Econet, Ethernet, AUN).

3.6:  CMOS contains both machine-specific and user-specific state; the former
is naturally "global", whereas the latter is URD log-on specific. This
proposal deals with CMOS as a single lump, which means that network managers
will always be faced with a difficult decision as to where CMOS should be
loaded from.

3.7:  Acorn has already advised ISVs on how best to store application choices
in a network environment. This proposal must take these recommendations into
account, and Carl Sellers has supplied appropriate documents to the team.

3.8:  The provision of a Boot floppy from which to boot a network only
machine when network booting has failed was discussed. Some reviewers felt
that this would give the wrong message, since such a machine may be almost
unusable - although they were reassured that the aim was to make the machine
as useful as possible consistent with other goals of the project.

3.9:  4.3(1): Note that CTRL/BRK and CTRL/RESET will start the boot process
as well as power-on.

3.10: 4.3(3): Replace "client machine internet address" by "client machine
address", and cross-reference to where this is defined.

3.11: 4.4(g) and elsewhere: There is no need to place suitable MDFs in ROM
for display after a booting error; this simplifies the specification in a
number of ways.

3.12: 4.4(d): Choose another name for the "Keywords" module - perhaps
"BootSupp" or "BootUtils". This module must be internationalised.
[PMN: the module is to be called "BootCommands"] 

3.13: 4.4: The idea of applications appearing in the Apps directory viewer
as a result of their having been "seen" by the filer was not liked; in
particular we must not encourage ISVs to include *AddApp commands in their
!Boot files. The requirement is only that the Apps viewer should contain the
normal set of applications after booting.

3.14: 5.1.4: When a client machine boots up, a search is first made for
machine-specific configuration files (Desktop, PreDesk etc.). If none are
found, then network global files should be used instead (RO350.Hook.Desktop
etc.).

3.15: 5.1.4: Should the procedure outlined in 3.14 apply to the loading of
CMOS images as well?

3.16: 5.2: Replace "ARPlayer" by "ARMovie".

3.17: 5.5: MchConfig should process Choices.<app> directories as well as
Choices.Boot directories; see the Medusa PRM 5-223pp and the Choices notes
supplied by Carl.

3.18: 5.5: It would be helpful if MchConfig's dialogue box indicated whether
the CMOS-locked link is set or not.

3.19: 5.5: The MchConfig dbox is not Style Guide compliant; the order of the
action buttons should be Default, Cancel and Save.

3.20: 5.5: Consider removing the "Default" option: it is very easy for a
network manager to simply delete machine specific configuration files when
required (and "silent" deletion by MchConfig may be confusing).

3.21: 5.5(c): Remove the sentence in brackets "(An attempt ... effect.)"

3.22: 5.6: Clarify which commands are new, and which pre-existing.

3.23: 5.6: Re-consider which bytes of CMOS are not overwritten by LoadCMOS.

3.24: 5.7: There may be technical difficulties with booting from floppy disc
after a problem is encountered during network boot. If these are significant,
then this option should be removed. In any case, the wording should indicate
that such a boot is an emergency boot only.

3.25: 5.9: Current Medusa production requires different disc images for
machines with VRAM as opposed to those without VRAM. Orlando has identified
a solution to this problem, which should be incorporated in Black.

3.26: 5.10: This section will not be needed if MDFs in ROM are removed.

3.27: 6.3: Clarify which monitors are to be supported. There may be a need
to provide different MDFs for the same monitor for different platforms: can
this be supported by the present structure?

3.28: 6.3: Make sure that the Orlando RomPatch file is placed in RO350.Hook.

3.29: 6.3: Note that bandwidth limit is platform-specific rather than
OS-specific, and there may be other configuration values with this property.
Is there any general way to support such values?

3.30: 6.3: The proposed configuration structure is suitable only so long as
3.60 is the latest version of RISC OS available: as soon as a machine running
a later version of the OS is added to the network, the structure would need
to be changed. If possible, a solution to this needs to be found.

3.31: 6.3: Check that our VProtect licence covers distribution as part of
Black in this way.

3.32: 6.5: Note that each machine's unique address will be derived in the
way that !Scrap uses.

3.33: 6.8: Note that Alias$Logon is set only for the duration of !Boot.

3.34: 6.11: Check out the proposed !System with Tony Sumner, who is believed
to have experienced some problems with a similar proposal in the past.

3.35: 6.11: Are there problems when a machine with a hard disc (and a !System
on it) is booted from the network where a "global" !System has been found?

3.36: 6.11: Consideration should be given to a situation where two !System's
can be active at the same time, with modules loaded preferentially from the
local hard disc (where present), but with a fallback search of some directory
on the network. [PMN: given timescales, this is likely to remain a future
enhancment.]

3.37: 7: Add Style Guide compliance to the "standards" list.

3.38: 10: Dependence on Kryten hardware is not relevant here.

3.39: Further targets - such as target boot time for, say, 16 machines - need
to be added to the Acceptance test section; Charles Whyte has offered to help
here.

3.40: Consider the implications of booting from a hard disc, and then logging
on to the network.

3.41: Support for third party networks should not be seen just as a future
enhancement. A copy of the next version of the specification should be sent
(under NDA) for comment to appropriate ISVs (such as SJ Research and Digital
Systems); Sue Wall will be able to advise here.

3.42: Check that it is possible to place !Territory on a fileserver for
nationalisation purposes.



4  Timescales


Timescales are very tight, with software due to be frozen for audit in the
middle of October. This is an area for concern, as highlighted in section 2.1
above.



Mike Challis
12th September 1994
