Marco

Marco is a long term project within the Architecture Unit at the CRC for Distributed Systems Technology. Its aim is to produce a user environment suitable for a global distributed system.

Overview

A user environment consists of many objects presented to the user visually and/or audibly. Typically, many of the object you wish to manager are poorly presented, requiring indirect access via various tools.

As an example, a Unix process is an object you might wish to manage, but its interface is via ps/top/kill, via an xterm, via your window manager. Other examples that are particularly gruesome are local files, remote processes, DCE servers, etc.

The WWW attempts to provide a single user interface to a number of object classes. It is admirably successful, provided that you only want to read (not write) and the objects are of a limited set of classes. A major problem is the inability to extend the set of handled classes easily. Another is the inability to customise the way in which objects are presented.

Marco manages objects, their classes and access to them. It overlaps the functionality of a window manager, web browser, file manager, mail reader and many other tools. The aim is to allow users to manage all their objects via a single framework, with personalised presentation.

Status

The project is in an exploratory design phase at the moment. Various ideas are vying for consideration and subsequent prototyping.

Previous work has focused on infrastructural requirements, generating a means of accessing previously unknown DCE servers and a simple GUI tool which uses this capability in a DCE service browser.

Current effort is directed towards establishing the "plugin" interface for data presentation and some useful Collection presenters.

Marco will consist of several integrated components

Data Presentation
Object Reference Management
Scripting Language
Object Browser

Data Presentation

Marco includes a means of 'getting' (displaying) and 'setting' (user entry) instances of basic types. These might be fairly primitive, but guarantee that the user can create and retrieve the parameters to any object method and access commonly used enterprise types (such as text or PostScript).

Much more useful though is the ability to specify an alternative means of displaying data of a particular type. This can be as simple as a customised wrapper for integers, to defining a complete forms-style application to front-end a complex binding type.

We are already familiar with this kind of functionality when using WWW browsers. These examine the type tag at the front of the URL and determine how to get and display the information. This can include using your .mailcap file to determine your customised requirements for dislaying that type of information.

Marco will include this ability, but extend it.

Data presentation in Marco is based on types as determined by the Type Manager. These are much more flexible than those supported by MIME, and conseqently by the WWW.
The use of a .mailcap file gives a personal set of customisations which override the system defaults. Within Marco, a more flexible scheme will allow the user to override presentations on the basis of locality, time, context, etc.
Definition of a new type tag for a URL requires the submission of a revised specification to the IETF RFC process. This takes at best of the order of months to obtain a new type. Type Manager types are available to all connected systems within seconds.
A graphical editor allowing the specification of presentation preferences and testing of their selection in different circumstances will allow naive users to customise their environment successfully.
This is also related to the concept of "plugins" as used by Netscape Navigator. See their description of the interface.

Object Reference Management

Anyone who has used the net for a while ends up with several collections of pointers to 'things' that are interesting or important and are stored away for use when you get the time. I've got a Web hotlist, a stack of mail folders (which also store news clippings) and a tmp directory full of little bits and pieces.

In different circumstances, you want to use these references in different ways. Sometimes a graphical file-manager style inteface is appropriate. For scripting, a simple listing of their names is most useful. I frequently access them looking for most recent additions first.

Marco will provide a generic notion of collections - a group of references to objects which may be local or remote and of any type. Since a collection is implemented simply as another local object, collections can be nested.

Multiple presentation methods for collection objects will support displays ranging from a textual listing of the reference names though to complex three dimensional animated icons representing the references.

Object Browser

Influenced by the Class Browser from Smalltalk and the various WWW Browsers, the Object Browser allows you to manipulate objects. Using the services of the Type Manager, the browser can determine what operations and state the object exports and allows you to access them.

The major issues here are how to map from the presentation to the browser. If you choose to display a Unix directory object as a graphical tree - each file object is a browse-able object. Similarly if you display it as sorted text names, etc.

Each class has defined actions which may then be filtered by a presentation before being made available to the user. Normally, a right-button click will produce a menu, and a left-click perform the default action. Does this apply to most presentations?

Scripting Language

Used both in defining new presentation methods and for creating compound objects, Marco will provide a programming environment the supports scripted manipulation of object references including interaction between them.

Currently the most likely language for this purpose is Python. Of course we should support multiple languages - but this will not be an immediate priority for us.

David Arnold