WOM's portability, and how it relates to SLP and Object Rexx

The idea for WOM originated in SLP, a new programming paradigm based on two branches of mathematics, sheaf theory and category theory. In brief, the theory behind SLP provides a way of calculating a description of the behaviour of a system of interacting components, given specifications of these components' own behaviours and the way they interact. These descriptions can be executable, i.e. programs. For WOM, the components are Web user-interface elements such as fields and text-output regions, the system is an entire application such as Tow, and the interactions between elements are the way that one instance's attributes depend on those of other instances.

The original conception of WOM was that behaviours would be specified not as Object Rexx code inserts but as systems of equations. As a simple example, the equations below specify that the value attribute of instance output is to be 0 at time 0, and otherwise to be equal to the previous value of input's value attribute. The time coordinates are given by server accesses, so time 0 is the time when the pages are initialised, time 1 is the time between the server receiving the first request and sending a page, and so on.

<Behaviour>
output~value[0] = 0
output~value[t] = input~value[t-1], t>0
</Behaviour>

There is nothing special about Object Rexx here. It would be just as easy to compile into Java, C++, or some other OOP target language. Code inserts would be written in the same language and merged into the target code, with the compiler translating paths as it does now for Object Rexx. Thus there can be a whole family of Web tools: Web-O-Matic/Rexx, Web-O-Matic/C++, Web-O-Matic/Java and so on. The reason for using Object Rexx were that:

1. It was available. Java for OS/2 had only just been released, and we didn't want to program in C++ if at all possible.

2. Many of our pages need to start programs and to interact with the operating system in other ways. Rexx was designed for this.

3. The language makes it easy to create instances in one invocation of a server script and to pick them up in another. Instances created by a command file will survive after it has exited, provided a pointer still exists to them. We store these pointers in a directory which is in turn stored as an element of .environment.

   If doing the same thing in Java (say), one would normally need an ``instance manager'' process to be permanently running. Instances would live in its memory, and could be created and accessed by messages sent to it via pipes or sockets.

  One problem with the current implementation of WOM is that the Web-page author does sometimes need to be careful about the sequence in which Behaviours are executed, to ensure that instances are updated in the right order. Although it is much easier to program Web applications in WOM than with most other CGI tools, the ability to use equations would make it easier still. However, before this can be done, more work is needed not only on code-generation, but also on the semantics of inheritance. This is different from that in Object Rexx and other conventional OOP languages: although cleaner, we are not yet sure how best to use it in designing a concise and author-friendly notation for describing Web applications. In the meantime, the intuitive use of SLP on which WOM is based has already proved its worth.