Features under consideration for the future

Amiga Mosaic is a constantly evolving piece of software. We have many plans for the future, some of which are described below.

Inlined Multimedia

Under consideration is an extension of the inlined image facility which will allow for other types of inlined ``objects''.

In particular, we hope to support inlined sounds, and inlined animations. Inlined sounds would either be played for the user as soon as the document (and sound) is loaded, or would be represented by an icon, which the user could select in order to play the sound. The sound would not have to be reloaded each time the user wishes to play it. An inlined animation would display the first frame of the animation in the Mosaic window, along with ``tape player'' controls that would indicate that an animation is present, and allow the user to control it's playing.

Both of these additions would be implemented using the same Datatypes system which is currently used for inlined images. Playing a sound through Datatypes is trivial, and will probably be implemented first. An animation will be more complicated, but is possible. An Amiga ANIM Datatype driver already exists, which will allow us to experiment with existing Amiga animations in Mosaic. Once the code is in place in Amiga Mosaic, a user can install an MPEG Datatype, and inlined MPEGs will then be possible.

ARexx

The following lists some features that are being considered for addition to the ARexx interface in the next release of Amiga Mosaic.

Wedge

The wedge command would allow an ARexx script to be triggered at various stages of fetching a document. The possible trigger stages include just before the document is fetched, allowing it to change the URL; instead of fetching the document, allowing it to provide its own data; or after the document is fetched, allow post-processing of the data.

The possible uses for this command include displaying inline images as external images on platforms that don't support inline images, or using a terminal program as an external processor to download documents from a normal shell account to local files.

Display

The display command would allow a ARexx script to send an HTML document directly to Mosaic to be displayed. This would make user interaction much cleaner than it curently is, where error messages either don't exist, or are displayed by an external facility. What the URL for the displayed document should be is an open question.

The REXX: URL

To bring full ARexx support to Amiga Mosaic, it needs some facility for sending ARexx messages via other methods than ARexx scripts. The REXX: URL should provide this facility, but is as yet no more than an idea.

The syntax under consideration is REXX://hostname/portname/message. portname is the application to send the message to. For now, there are no standards for sending ARexx messages to remote machines, though some have been discussed.

The general mechanism would be to decode the message as a URL, and send the results to the given portname on hostname. The result string from the script so invoked would be displayed as HTML text.

Using a GET method in an HTML form would allow ARexx scripts to serve as client side processing facilities with no more than this mechanism. The ability to use the POST method and send data in via standard input is desirable, but there has been no work on that.

Persistent Data Cache

Another important feature missing from most clients is a way to cache data, and especially images, locally. One of the more frustrating aspects of the Web is waiting for inlined images to load. While some proxy servers have addressed this issue, a cleaner way would be for the client to handle the caching.

There are two very different ways of implementing a disk-based cache in Amiga Mosaic. One is by directly writing cache handling code into the client. This code would check the disk cache before accessing a document over the network, and save any transferred documents to the cache. A second way of implementing the cache would be to write Rexx scripts and hooks which would use the wedge command to intercept fetch requests and return appropriate documents from the local cache. When documents are transferred over the network, the wedge command would call a Rexx program to save the document to the cache.

Both methods would have the ability to take advantage of the more advanced server features such as the Date mime header and the GET if-modified-since directive.