Tornado's design concept

Introduction

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

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.

What does tornado do?

• All user interactions. When the user clicks on an icon in a program's window, tornado looks up the attributes attached to that icon. The attributes are essentially a string which says for example "A double click over me calls function X, a single click calls function Y, a triple click with Alt and Left Shift calls function Z, and also please colour me &7f7f7f, put a sprite S from my private pool in me against the right margin with the following marked-up text [1] formatted around it, and oh BTW if the pointer is over me, call function J too, and if I am visible in any way, then display the sprite ANN with the count incrementing and looping through 0-59 every vsync". Obviously, this huge list is condensed into a very compact and unreadable set of single-letter attributes, and tornado will also save memory by linking icons with similar attribute strings into using the same string.

  I would also add that you define attributes for everything (eg; title bar, work area (which is also an icon) - everything), and that via extension modules you can add new attributes for everyone to use. Also, "simple" file types can be directly edited by tornado for you, so if you wanted you could have the text in your icon editable and formatted. In fact, tornado directly provides editing for any of the "tornado" file types (more about which below).

  [1] - marked-up text on tornado is like normal text except it can have escape sequences allowing you to change the style etc of the text and even to attach code images, functions or other documents to a selected piece of text.

• File management. Tornado handles the loading and saving of all files for your code, converting them into a type readable by your code if necessary. It also allows a file loaded into one program to be edited directly by another program while still remaining in its original place, and also multiple views of the same file can be dragged and dropped into multiple programs or even limitedly into RISC-OS.

  Tornado will also allow programs to edit files far larger than machine RAM size, and additionally standard tornado file types can be directly edited by tornado for you using a suite of user-defined tools.

• File rendering. Whether the file be textual, graphical, audial, raw data or animated, tornado will handle the drawing/plotting/playback/display of the file for you. In other words, you do not need the application that created a file in order to view it.

  As an extension to this, files capable of being printed will be printed for you by tornado at the best quality the printer allows.

• Menus. RISC-OS style popup menus are provided automatically by tornado for applications through the use of the tornado script language. Items in menus or whole menus themselves can have attributes attached to them, allowing their rebuilding upon conditions changing as specified by the script.
• Help. Tornado supports three types of help - the first is very basic, simply displaying a book's name, chapter, page number and short description. The second consists of simple marked-up text, and the third is the former but with hypertextual, multimedial and interactive link-ins, allowing automated default config-builders to be called for example, or perhaps the direct manipulation of the program as the help text can have a function in the main program image called.

  Obviously, you would install the latter for a brand-new program you have just bought and would deinstall it to either of the first two levels when you had learnt the program, thus saving resources.

• Preemptive multithreading multitasking. Multiple threads of multiple programs can be executed simultaneously by tornado, and individual threads can be passed to other processors in the machine or outside it. Also, when non-multitasking programs are started up, an environment is created for them to live in and run that is identical to that if it were not being mulitasked. The multithreader is automated, but can be overriden by user preferences when wanted.

  Threads are constantly monitored, and should one become unpreemptable for more than a second (ie; it crashes), tornado will intervene and halt the task. It then will ask the user if it wants to save out the files being edited by the task, or simply restart the task with files intact, or even return to the program and leave it crash! This procedure is also more or less followed upon Address Exceptions and all of the other hardware and software errors.

• Subtask and applet management. This however is usually transparent to the program as these facilites are usually called by tornado for the program by examination of an attribute string. Needless to say, subtasks and applets can be exported to other processors or non-local computers as well.
• Multilanguage capability. Tornado directly supports multiple languages which are Roman/Arabic based, although not any of the Asian languages. Tornado will automatically select and display the correct language from your messages file for you.
• Standard i/o utilities. Tornado allows programs to use centralised libraries of i/o utilities to access serial/parallel/radio etc, permitting x/y/zmodem transfers, a TCP/IP stack and associated utilities etc all done using a standard interface.

Data streams

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:
   • If there isn't, then tornado does some guesswork. Tornado will know that the file is general type embedded from the filetype headers. DTP files have to be general embedded as they actually contain a host of other files (subfiles) which are embedded within the main file [1], and the embedding of subfiles within such a file is done in a standard way for all DTP files [2] created by tornado programs. So, it asks the user if they want a basic rendering, and if they do it essentially renders the embedded file as best it can [3] in much the same way as if there had been a renderer present.
   • If there is, the renderer is paged into memory, the window opened, and a new data stream created between the file, the renderer, and the window. Essentially, the file is pulled off the disc, passed to the renderer, which converts it to graphics, which then are output into the window.

[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).

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.

• With Select:
  • Double-click - view file
  • Shift double-click - view file as a binary
  • Ctrl double-click - edit file
  • Ctrl Shift double-click - edit file as a binary
• With Adjust (you must hold the last click as it puts the pointer dragging a file):
  • Double-click - link a view of this file to wherever the file icon is deposited
  • Shift double-click - link a binary view of this file to wherever the file icon is deposited
  • Ctrl double-click - link an editable view of this file to wherever the file icon is deposited
  • Ctrl Shift double-click - link an editable binary view of this file to wherever the file icon is deposited
• With Alt and either of the above (Select or Adjust), a new data stream will not be created - a whole new copy of the file will be used instead (ie; changes you make to this view/file will not effect the original or any of its views).

[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.

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!

• Auto-installers that can be bypassed if they don't work.
• Tornado never forces you to do anything eg; if a program crashes totally, and tornado halts it, tornado will never stick a Cancel box in your face, halt multitasking or tie the pointer to the box. It will give you a list of options, including "Return to the program & ignore the crash", which is as dangerous as it sounds but if you want to do it, you can.
• Tornado, obviously, supports multiple users. However, multiple user definitions can be existing one one computer - allowing John to have his windows and multitasker function one way and Janice have hers another.
• There are loads of ability to tie script segments to hotkeys that allow you to do that last example with just one keypress. Or better - have it take all the files on the hard disc starting with T and ending with o and which have a space in and are of type JPEG and perform a certain hotkey on all of them. BTW, it doesn't do each file one by one necessarily - it can do the entire lot at once!
• You can write a simple text editor in about fifteen lines, a simple graphic editor in roughly the same, an email editor in about twenty ... that's because everything is in tornado, so only things like a Virtual landscape fly-through etc would really have any code. And if they were any good, I (or someone else) would ask them to submit their code to the library so everyone could benefit.

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? ;)