Concluding remarks

An approach for building tailorable systems has been shown. This approach is based on having a generic framework for building systems in the relevant domain, and instantiating it into a specic system that includes an interpreter for the original development language.

In addition, the specic system has \open points" through which new classes can be installed. The resulting system is then tailorable in a manner similar to systems which run in residential environments like Lisp and Smalltalk. It supports extensions to the underlying framework at runtime.

The approach has been demonstrated for hypermedia systems. The construction of a highly tailorable hypermedia system has been shown. The tailoring process in order to install a new drawing media-type has also been shown. Problems encountered in saving interpreted objects into a persistent store or OODB have been resolved.

It is important to note that in this approach, the designer of the system has control over where the open points should be, and as a result, has control over what should be

15By extension-interface of a class is meant only those aspects of its signature and behavior that aect extensions of it.

tailorable. Thus, the resulting tailorable systems do not allow users to make arbitrary changes to the system, as can be done in Lisp and Smalltalk environments.

An advantage, which is also a limitation, of open-points in Beta is that extensions written by the user cannot easily break functionality already present in the system. This is mainly due to the semantics of Beta, and is discussed in great detail in [Mal94]. In Beta, sub-classes are true extensions of their super-sub-classes; a sub-class renes its super-class, it does not replace parts of its super-class. This limits what can be done by the extension, thus limiting the damage-potential of the extension.

A tailorable system built using this approach will probably not be tailorable by a non-programmer user. As has been demonstrated in the paper, the tailoring process requires a small coding eort and a reasonable command of programming. Most use-sites, however, have super-users who could easily be able to do this kind of tailoring [Mac90]. An exten-sion to this approach would be to build a specialized application-oriented language and environment atop these open points; this would make the coding eort much easier. So, the tailorable system, instead of asking the user for Beta source-code les could instead provide an environment for the user to construct this code. This environment could be specialized to, say, the hypermedia domain, and provide constructs to directly support hypermedia-system extensions, e.g. the denition of new media-types.

In this work, the Beta interpreter has been utilized to process and load dynamic exten-sions. As described in [Mal94], there are other alternatives to this: one could also use the Beta compiler to compile the source and a dynamic linker to link and load the compiled object-code. This alternative approach would, however, not result in a stand-alone system unless the compiler and the linker are embedded within the tailorable system.

To tailor the example hypermedia system with the new drawing media-type, the user must have available, in addition to the system, the interfaces of the framework classes used. In addition, in order for the interpreter to be able to locate the object-code for these framework classes, some symbol-table information, generated during the compilation process of the original system, must also be available. This is all the information about the original system that is necessary. In our experiments, we had available, annotated abstract syntax-trees of the original system. These had more information in them than was really necessary. It should be easy to construct trimmed versions of these trees with only the necessary information. In fact, a prototype implementation of this is available as part of the Mjlner Beta system. So a tailorable system, built using the approach, must be shipped with this additional interface and symbol information in order to be tailorable.

To measure the overhead of using the interpreter approach, the following must be included:

1. the size increase of the hypermedia executable caused by embedding the interpreter.

Initial measurements indicated an increase of 1.3 MB.

2. the size of the linker-generated symbol-table which is part of the hypermedia ex-ecutable. Ordinarily, this information is not necessary for the hypermedia system to run. However, the embedded interpreter uses this information in order to ac-cess object-code in the hypermedia executable; hence it cannot be discarded. This amounts to 2.3 MB.

3. the interface les needed in order to interpret denitions of new media-types. This amounts to 0.2 MB.

The total overhead adds up to 3.8 MB. The size increase caused by embedding the in-terpreter (1.3 MB) can denitely be further reduced. The value presented is for the rst unoptimized version of the interpreter. In addition, forthcoming improvements in the Beta compiler show promise of producing smaller object-code les.

The size increase caused by retaining the linker-generated symbol-table in the hypermedia executable (2.3 MB) can also denitely be further reduced. The Beta compiler produces three symbols for each pattern it compiles, while the interpreter uses only one of these.

Hence, it seems like the number of symbols can be reduced by a third; thus, the table should occupy only 0.8 MB. This improvement in the compiler is also forthcoming. Thus, the revised overhead is only 2.3 MB.

In fact, if it were possible to trim this symbol-table to include only those symbols for which there were corresponding denitions in the supplied interface les, the symbol-table overhead could be further reduced. This should be possible by writing a variant of the standard Unixstrip command, which could consult the interface les to determine which symbols should be retained, and remove all others.

This overhead of less than 2.3 MB appears small in comparison with that of other source-code-level-tailorable systems. For instance, the hypermedia systems Intermedia and Note-Cards discussed in this paper seem to require a much larger overhead to provide similar tailorability. Intermedia was built using MacApp and MPW; major parts of these basic environments are needed, along with the Intermedia code, in order to tailor Interme-dia. These core parts of MacApp and MPW in themselves, by rough measurements, add 15 MB in overhead in terms of libraries and executables necessary for tailoring a system like Intermedia. NoteCards was built in the residential Interlisp environment; thus the entire environment is necessary both to run and to tailor NoteCards. An Interlisp image typically adds 12 MB in overhead for a system like NoteCards to be executed and tailored.

This overhead of 2.3 MB can also be compared with that of tailoring the DHM system using the Beta development environment. In this scenario, the user would create the

extensions as shown here, compile them, and relink the application. In order to do the kinds of tailoring we have described, the following would be necessary:

1. the Beta compiler. This amounts to 3 MB.

2. the assembler used by the compiler. This amounts to 0.15 MB.

3. the linker used by the compiler. This amounts to 0.1 MB.

4. the object-code les for the DHM development framework. This amounts to 3 MB.

5. the object-code les for the other basic libraries, e.g. the Xt library. This amounts to at least 1.22 MB.

6. the interface les needed in order to compile the denitions of the new media-types.

This is the same as what the interpreter needs and amounts to 0.2 MB.

Thus, the total overhead is 7.67 MB, or 333% of the interpreter-approach overhead.

Yet another scenario can be considered. Here, the compiler would be used to compile the extension, and an incremental | dynamic or static | linker used to link the exten-sion into the DHM executable. In this case, the object-code les would not be necessary (4.22 MB). There would, however, be need for the symbol-table (0.8 MB) as in the inter-preter approach. In such a scenario, the overhead would be 7.67 - 4.22 + 0.8 = 4.25 MB, or 184% of the interpreter approach overhead.

Even though the drawing editor, and its presentation class, are interpreted, their perfor-mance is acceptable. It, however, remains to be seen how the interpreter would perform in the case of a cpu-intensive media-type like video. The time taken to extend the hy-permedia system | with the built-in interpreter | with a new media-type is, however, a small fraction of the time it would take to compile the necessary sources and relink the system.

It has thus been shown that we can provide close to the level of tailorability of systems like NoteCards and Intermedia, but at a fraction of the overhead, and with potentially greater safety.

Acknowledgements

This work has been supported by the Danish Research Programme for Informatics, grant number 5.26.18.19, and the ESPRIT II/III projects EuroCoOp and EuroCODE. We greatly thank Randy Trigg for his contributions to the development of the DHM de-velopment framework. Thanks to Lennert Sloth for helping with the numerous problems

in getting the tailorable hypermedia system working. Thanks to Sren Brandt for help with the persistent store.

Appendix A