The Datafile PD-CD 5/DATAFILE_PDCD5.iso/utilities/t/tornado/Aims

Text File | 1995-07-14 | 8.2 KB | 137 lines

This document attempts to explain the underlying ideas behind Tornado. They
are short and sweet (only three), and so thus should not be taken lightly.
They attempt to define conclusively what Tornado is aimed to be, and become.

First and foremost, a few terms should be explained. In ordinary English, the
following probably mean much the same, but as referred to here they are
different:
   A Tornado programmer is a coder who uses Tornado, in any shape or form
(including ideas) to write his/her program with. He/she doesn't _have_ to
actually code supplied by the Tornado group.
   A Tornado developer is a coder who is actively writing Tornado, and takes
an active part in supporting it. They don't necessarily have to programmers,
but can be "mere" icon and graphic designers - you don't need to be a C++
whizz-kid to participate. Also, beta-testers are included in this catagory.


Aims of the Tornado project:

   1: The first, and primary aim of the entire Tornado philosophy, is to
increase productivity for the user.

   To this end, the Tornado suite of resources will be carefully designed to
ensure the user will not meet with 'niggling' problems, like missing fonts
causing a recurring irremoveable error for example. Also, the Tornado
resources should be written in such a manner as to gently push the Tornado
programmer in a direction that is consistent with the Tornado general look
and philosophies.
   Added to this, Tornado applications must be frugal with processing power,
memory, and disc space. This is so more can be done with less. An example of
where Tornado does this, is the availability of changing filetypes in line -
for example, if a GIF file is dragged into a Tornado app that can only read
Sprites, the file is converted before being passed to the app. This saves
disc space. Or adding preemption: this allows continuous flowing polling. Or
virtual memory: this allows a sprite editor to edit a 2560x2048 32bit sprite,
which would normally take 21Mb plus of RAM, with only 1Mb of memory (albeit
4Mb would decrease disc activity somewhat!), thus saving on memory needed.
   To this end there will exist a 'vetting' procedure, allowing Tornado
programmers to submit their code for review. If the code passes, then the
program may be labelled as a program conforming _fully_ to the Tornado
standard. This will attempt to make (especially commercial) programmers write
consistant code which uses Tornado to the full ie; somehow disabling RAM
transfers or not using external subtasks when they should will fail a
program, as doing this detracts from the aims of Tornado.
   Some people on the rather paranoid usenet have expressed worries that
Tornado will force writers to write identical code, which is boring and lacks
the individual touch. What should be noted here, is that the vetting
procedure costs quite a bit of money (£50 minimum, moving upwards with size
and complexity of the program], and is really intended for commercial
writers. PD writers will no doubt forego the vetting process, and we are not
too worried by this as PD apps usually are downloaded on the basis of
strength of word, and thus any rogue apps will be left archived and unused.
   Just because Tornado is aiming in a particular direction doesn't mean all
programmers using it must conform as well. Even if we tried to enforce this
we would fail. No doubt the PD apps scene will remain as varied as ever,
although it is hoped PD writers will try and make their apps as complient as
possible, to aim for a better desktop all round.
   However, if anyone reading this is still worried, please feel free to
write to one of the Tornado team.


   2: The secondary aim is to create a convention, a standard, which will set
the means by which all other RISC-OS applications will aspire to.

   This means that Tornado programs will utilise features and aspects of
today's computing in excess of the current status quo. For example, the
subtasks as provided by Tornado are rather TAOS-like in structure and use.
Tornado provides OLE, virtual memory, relocatable heaps etc. as standard in
all applications (if they choose to avail of it, which is pretty difficult
not to do) and this fact will increase productivity for all users using
Tornado applications. Tornado also has a number of features indicative of a
superior nature, like tfs: is written to be extremely quick, allows spaces in
filenames of unlimited length, unlimited depth of the filing hierarchy, and
has support for 32-bit filetypes when they come out.
   The protocols and features implemented in Tornado are also constructed for
speed, frugality and efficiency. Many of the protocols and features also use
aspects and variations not currently heard of on any platform, and it is
intended and hoped other platform developers may listen and learn, as will be
noted when a certain GUI comes out: note how similar it is to the RISC-OS
desktop and how they've hashed up the icon bar? :-)
   Finally, Tornado developers will be drawing up, considering, and
developing protocols and standards which it is hoped will form much of the
new development work on RISC-OS, which to date has been rather lacking. Also,
a standard will be created, meaning less of one program using one standard
and thus being completely incompatible with another program using another
standard, which hinders productivity.


   3: The tertiary aim is to make life as easy as possible for the
programmer, whilst not damaging the previous two aims.

   This essentially is the same as what FileSwitch does for FS writers. Those
of us old enough :-) will remember trying to write filing systems for 6502
based machines. RISC-OS 2 was such a boon because it took away all the
drudgery, and imposed a loose standard for filing system's to follow. This is
what the Tornado shell intends to do for Wimp apps, taking care of things
like loading and saving automatically, opening windows and dialogue boxes,
OLE and hotlinking etc (see the Tornado brief). It is proposed you could
write a good text editor in less than 8k of !RunImage, and a multi-format
file viewer in about 2k.

Notes:

   There has been an odd trend in recent years to produce huge libraries of
code and not actually go further. Thus you get one program using Interface,
another using WimpExt, another using ABCLib in various odd combinations.
There is a lot of already written library code out there, for all languages,
all needs. However, they are all stand-alone objects, and this is probably
understandable. Also, libraries like DeskLib, although excellent, apply to
AOF format languages only, and thus Basic gets left in the dark, which
shouldn't be the case, despite Acorn's stupid attitudes.
   Tornado isn't intended to do this all over again. There are some fine
libraries of code out there, and Tornado intends to build on them rather than
rewrite them. To this end, it is part of the Tornado project to search out
sections of already written code, and merge them into Tornado. This should
save some work on the behalf of the Tornado developers. In other words, if
you know of a bit of code (either yours or someone else's) which does
something you think would be useful to Wimp writers at large, give us a
shout. You won't get any money, but you will get a mention in the Tornado
docs.
   To this end, Tornado will rely on auxillary libraries. Those decided upon
for definate so far are RISC-OS 2 (it /is/ a library!), WimpExt by Jon
Ribbens v2.18 from Doggysoft, and the DragASprite module by Andrew Clover
v2.01 also from Doggysoft. Currently I am seeking out version 3.50 of
WimpExt, but as yet to no avail. Can anyone help?
   TBH I can't see any need for many more libraries. WimpExt provides
everything from quick memory copying routines to rendering Draw files, and
Tornado will use WimpExt to its fullest extent. DragSprite+ is used, also
from Doggysoft as the DragASprite module in RO3 isn't as great as it could
be, and this DragASprite+ is completely flicker-free, even in mode 21 on an
Arm2!
   This said though, most of Tornado is written in C, and sections of C code
from other sources will probably be mercilessly ripped out and incorporated
into Tornado. We will seek copyright permission first though. Also, the C
sources will not use ANSI C libs, as they rather badly affect the compiled
product (ie; large & slow), and also this means they won't be relient on any
resident modules.