(Note that this page hasn't been updated for tornado II yet)

Tornado's design concept


I suppose tornado could be described as the logical tying together of stand-alone concepts already used in the software world. Perhaps this is true - many of tornado's design concepts bear a striking resemblance to stuff being pushed by Apple, Sun and IBM nowadays. This was not intentional by any means - I only realised that OpenDoc® was so similar to tornado's file editing management two weeks ago when I read the specs at Apple's site. The ability of tornado to export processes to external processors is very similar to Sun's Hot Java® applets, except of course that the latter is platform-independant whereas tornado is firmly tied to the ARM architecture.

BTW, the list below may not appear right - that would be because I've put a definition list into an unordered list. I don't see any reason why browsers shouldn't be able to display them correctly, but as Webster mucks up - well!

Also, apologies for the shortness and lack of detail of this page. It'll be much much longer by the time I'm finished, don't worry!

Niall Douglas (17-04-1996)

Design methodology of tornado

The fact is that I came up with these concepts entirely on my own by logically extending OLE, oddly enough, and by adhering to the following design rules (in priority):
  1. The foremost objective of tornado is to increase productivity
    Since the early eighties software designers have consistantly tried to make computers easier and easier to use for people who don't want to use them anyway. I feel that this trend has run its course, and that computers should now return to the course they were created for - as a tool to aid human productivity. And I think that making things condescendingly simplistic or worse, restrictively simplistic (eg; Win95's awful Plug and Play) does not help productivity much and saps resources better funnelled into developing computer<=>human interfaces.
  2. The secondry objective of tornado is to be frugal with resources
    Not wanting to be nasty, but the full Win95 runs at only a usuable speed on a P75 - certainly not breath-takingly fast anyway. It also requires hundreds of Megabytes of Hard disc space and 16Mb of RAM to run properly. Forgive me for pointing this out PC owners, but that is crap! An operating system should be quick and responsive, not consume vast tracts of memory to do simple operations, and not to take up vast stretches of disc space either.
  3. The tertiary objective of tornado is to remove as much programming from the programmer as possible
    In today's cut-throat software industry, large pieces of software have to be output quickly and easily and to that end some very effective development tools have been developed. However, the one single lack of these tools is integration with the environment. Tornado has a visual method of interfacing with code, and the design of full applications is similar. However, because resources are shared and little code is required to write a tornado application, they are quick, flexible, and small unlike the tombs of code produced by other visual editors.
With these concepts in mind, I then set to work on the design of tornado.

What does tornado do?

Tornado is a highly complicated piece of engineering. Here's some of the things it implements for all code running under it: Tornado also provides a number of standard interfaces to commonly used services/facilities:

Data streams

Probably the best way to illustrate data streams is to do it through example, as anything else I've tried writing about data streams comes out almost unreadable!

Say a user drags a DTP file onto the tornado viewer. What happens?

  1. Tornado examines the file to see if it's a tornado one. If it isn't (ie; it's a RISC-OS type), tornado passes the file to a routine which determines the filetype and whether it requires converting or not. If it does, a temporary file is created which is a tornado conversion of the RISC-OS one.
  2. The tornado viewer's script is checked, and this will state that a new window should be created and the file be displayed in it. Tornado creates a new window
  3. Tornado checks what kind of file it is (ie; DTP)
  4. Tornado searches to see if there is a renderer available for it:
[1]: Note that this is different from marked-up text by virtue of the fact that general embedded files contain all the necessary data in the ordinary sense (ie; not font data etc) required to render the file, whereas marked-up text's markups refer to data contained outside the actual file ie; the marked-up text is not necessarily enough to render the file fully in the ordinary sense.

[2]: Note that the thing that distingishes between different DTP filetypes is the file extension area which allows data to be included in the general embedded file which distinguishes it as one which came from one particular DTP editor.

[3]: Note that general embedded also covers tracker-type files (composed of sections of sample and tracking data), Draw and ArtWorks files (composed of other Draw, Artworks etc files and data required to put them together plus draw line segments etc). However, it would NOT cover bitmaps (including LZW compressed files like GIF), Sprites, JPEGs or animations like MPEG, but it would cover Replays and AVIs as they have the picture and sound seperately contained within the same file. However, as one can easily see, it is impractical to have standard file formats to be broken into this when already present renderers require them in their original format - therefore, tornado doesn't have to use files broken up like this, but it is assumed that any editors written for tornado will use the new format.

Some might argue that this complicates things a lot. You're right, it does. But the advantages of moving to this system are incomprehensible, and anyway there will be background converters to convert the files to a tornado filetype as necessary (as above).

Okay, so now the file is being rendered (BTW multitasking continues). Ah, I see a Sprite in a DrawFile in a frame on the DTP page. I want to edit it! So I Ctrl-double click on the sprite [1]. What happens?
  1. Tornado references the click and the mouse position to the Sprite file (which is an embedded file in the DTP file).
  2. Tornado searches for a program in memory capable of editing sprites. If there isn't one, it then checks all tornado programs known to it capable of editing sprites (tornado apps declare what they can edit in their !Boot files) [2]. It then loads it in if necessary, and creates a data stream between the sprite subfile and the editor application ie; the editor is given the file while it is still inside the DTP file, where it remains. Usually all the user sees at this stage is an editing window appear around the Sprite file, allowing editing.
[1]: The special reserved mouse clicks for tornado are: The reason for the differentiation between creating views and editable views is one of efficiency - a two way data stream is less efficient than a one-way one. Also, a viewing program is always available in the form of tornado whereas an editor program has to reside in memory and can usually only edit only one file type.

[2]: Note that if connected to other tornado systems (either via a local bus or network or whatever), all processes running on all machines connected together appear as though they are on the local machine to the local task ie; even if an editor was not available on the local machine, it may be on a remote machine. What happens here is that tornado creates a data stream between the file and remote editor as normal - the difference being that any interactions between the file and editor pass over the network. The user on the remote machine will not know that one of his/her applications is being used to edit a remote file by a remote user unless they actually look (or try and shut the editor down!). What is important to note here is that data streams can go between processes on a local machine or processor just as easily as between a local process and a process on a remote machine or indeed processes on different processors in the same machine but not the processor with the file on it. In other words, joining machines running tornado together simply creates a more powerful tornado in all senses, and also it means that tornado will cope with multiple processors as easily as it would multiple processes.

This also means that a view of a file ordinarily resident on a remote machine that gets dynamically updated when the source does is also possible. Or the monitoring of a student's work by a teacher. And of course, videoconferencing suddenly becomes possible in about ten lines of code - sample the camera picture and store it in a file which is being viewed by a remote process - the remote view will be automatically updated.

Note also that I have also just described how applets and subtasks are supported. In previous versions of tornado, subtasks were very much an external 'accessory' to the main task, which made sense for the design ethics of the time. However, now subtasking is so built in I'm sure you didn't recognise it above anywhere!

Anyway, applets would come into play here when you are talking about a very massive tornado network indeed, or on one where bandwidth is extremely limited (eg; the internet which is very slow in comparison to an Ethernet connection for example). In this situation (which may I add I haven't thought about much yet in terms of data streaming), it's either a throw-up between sending an applet Java style, or perhaps something a wee bit better - how about exporting the whole process running on the remote machine dealing with the local file to the local machine, wherein it can complete its processing, communicating with its original machine via data streams which it would use anyway - however, in this case having the process on the local machine cuts way back on bandwidth requirements as perhaps the streams accessing the parent machine's resources would be much smaller than if the process were on the parent machine.

Another major advantage of this methodology is that you can have a large powerful mother computer and loads of small cheap satellites. The tornado network between them all allows heavy processing to be done on the mother and yet allows all the satellites to get on with the job. This saves resources of every kind, and in the current climate of the NetSurfer it is a good one.

Right - we have just downloaded a JPEG of some nice woman we want to look at from the internet, and also print off a copy for a friend as well as paste it into a DTP frame and also uucode it and email it to another friend of ours. What do we do? We could do each thing one after the other, but why bother when tornado can do it all for us simultaneously and in the background while we get on with something else?

Firstly hit the hotkey to open the printer list (a window with all the printers currently available to tornado in it), and drag the JPEG file onto the printer you want to print from. A little arrow going into a little hat appears beside the JPEG file in the filer window, and a closed eye, grey arrow and a closed eye appear beside the printer icon in the printer list. What's happened?

(For an explanation of all the funny terminology below see here!)

Tornado realised the file was a JPEG and kicked in the JPEG to Sprite converter and the Sprite to (whatever the printer type was) printer data, followed by a disc buffer process, and linked them all together with a data stream. Thus, data is read off the disc, converted into sprite data, which is converted into printer data, which gets dumped to disc. Meanwhile tornado reads the data off the disc dump and sends it to the printer under interrupts.

Now, while it's printing, we want to have a look at it. We bring up the data stream flow menu by clicking Menu on the data flow summary, and create a new data flow off the JPEG to Sprite converter into a file viewer (alternatively we could double click on the JPEG file which would have tornado do the same thing unless the file weren't already being converted into a Sprite, in which case it would kick in the JPEG to Sprite converter). Up pops a view of the Sprite, updated dynamically as the JPEG gets converted.

Now we like the picture, and want to insert it into a DTP frame. So we double-click with adjust on the picture, which produces a draggable icon, which we drag and drop into the frame. Now the picture in the frame is dynamically updated as the one in the viewer is as the one going to the printer is. (Note that tornado has simply linked another data stream off the viewer into the DTP frame).

So now we want to uucode and email the picture to a friend of ours. So we put the pointer over the JPEG file, and hit the macro hotkey which we previously defined to do this - up pops a dialogue box asking for the email address, we enter the data and click okay. New data streams are put between the file and a data to uucoded text converter and to the text to email converter which then dumps into the TCPIP stack and flies off!

But what happens if your friend can't read JPEGs, only Sprites? So we do the same as above, but instead of kicking in a new process a pending data stream is created from the sprite to the archiver to the uucoder etc., with the pending data stream becoming active when the other data streams into the sprite terminate.

And of course, what happens if I close the viewer window from which a data stream is linked to the view in the DTP frame? Easy - the file is owned by tornado, not the viewer - simply the view of the file for the viewer is terminated, but the file remains in memory now essentially the property of the DTP package.

Phew! Now do you see why a non-by-example description of all this is so hard!

You may wish to see the icons data streams use. Try here!
Finally, I haven't mentioned the other parts of tornado which will make it so nice. Some of these are:
So, after reading this, what do you think? Do you think it's impossible? Probably. I don't. For 75% of the stuff above I can fish out data protocols and formats etc, and for the other 25% it should only take me a few weeks. I'll put them here if anyone's interested (probably not, and I'd have to admit I'd be worried about someone nicking them).

I suppose the next most obvious question is why hasn't anyone thought of all of this before? To be honest, I don't have a clue. It seems very straightforward to me, and the design of tornado isn't too complex really - although I haven't gone into how it works on the inside yet, I have all that done too. So why haven't the big software companies twigged this is possible yet?

Maybe this is one for Scully and Mulder? ;)

© 1996 Niall Douglas (Last updated: 17th April 1996)