Real-Time Multimedia and the Web workshop
Author: Daniel MAVRAKIS
Company: Monaco Telematique MC-TEL
Address: 25, boulevard d'Italie, P.O. Box 225, MC 98004 Monte-Carlo
Cedex, Principality of Monaco
Voice: +377 9216 8888
Fax: +377 9330 4545
Internet e-mail: mavrakis@mctel.fr
Date: September 12, 1996
VEMMI is a new international standard defining the user interface and client/server protocol for on-line multimedia interactive services.
This paper will introduce this new European (ETSI 300 382 and ETS 300 709) and international (ITU-T/CCITT T.107) VEMMI standard: "Enhanced Man-Machine Interface for Videotex and Multimedia/Hypermedia Information Retrieval Services" , and how it could be used right now to create on-line advanced multimedia services on the Internet, interworking with Web services.
VEMMI allows to create on-line multimedia and hypermedia services that could be accessed from any user owning a PC or Mac personal computer running a VEMMI client software, using any network (Internet, ISDN, videotex, and so on...) to access the multimedia server.
Figure 1: VEMMI defines and uses various objects (buttons, selectors, input fields, display areas for text, images, videotex or moving video) that are represented and managed in the user's terminal current operating system and graphic user interface. All the VEMMI objects are displayed as other objects of the current graphic user interface (Windows, Mac/OS, Motif, and so on...) and are managed in the same way. The multimedia VEMMI application could then be immediately used by any user that will see no difference between the user interactions of such an application or those of any local program executed by his personal computer.
VEMMI is a standardized on-line interactive multimedia protocol, allowing to create easily any multimedia on-line service, with the following features and facilities:
It must be strongly pointed out that VEMMI does not compete with but instead is quite complementary to the HTTP/HTML protocols used on the Web: VEMMI is for example not well suited to the display of documents linked by hyperlinks. Instead, VEMMI is designed to allow to create complex, high-value added applications using advanced features (multi-windowing object-oriented interface, continuous dialog with the host computer, use of client PC local processing facilities, and so on...) that will complement the Web and could be started during a Web session. To have more information on this point, consult the part dealing with VEMMI and Internet. You could also consult advanced technical information on VEMMI and Internet on http://www.mctel.fr/VEMMI/vemmi_internet.html.
Here is an example of actual VEMMI application: Figure 2: the demo Yellow Pages multimedia electronic directory built for France Telecom and demonstrated at Telecom 95 exhibit: the object-oriented, event driven, multi-windowing interface allows for example to search for an hotel in Paris, and in the same time looking at maps in another part of France.
One of the main interest of VEMMI is that it could be used on any network and low layers communication protocols, as it is fully independent of any network or transport layers. Typically, once the communication is established between the VEMMI client (usually a personal computer running a VEMMI emulator) and the VEMMI server, the multimedia VEMMI session could start.
VEMMI could then be used on any network (STN, videotex and X.25, ISDN, and so on), but one of its main area of interest is of course the Internet and TCP/IP networks. VEMMI is particularly interesting in respect of Internet or Intranet, as it offers an interactive multimedia solution that is quite complementary to the ones already existing in the Internet, mostly based on HTTP/HTML protocol (and using products such Mosaic, Netscape and other Web browsers).
As the Graphical User Interfaces (GUIs) currently used on personal computers and workstations (Windows, OS/2, MacOS, Motif, and so on...), VEMMI is object-oriented and use objects and resources. The logical units which form the structure of VEMMI are:
For the sake of simplicity, the term "VEMMI element" is a generic name used to designate an object, a component or an item.
Figure 3: Example showing the relationships between VEMMI objects, components and component items.
The VEMMI objects are the logical units used by the multimedia application to interact with the user. These objects are composed of several components.
A fundamental VEMMI characteristics is the objects are only defined by their function, their size and their position on the terminal screen. The actual object representation by the user terminal is not imposed and will be in practice the same that the one used by the graphical user interface running on the user terminal to display an equivalent object. This characteristic is of extreme importance, as it allows:
The VEMMI objects includes several components that belong to them. The VEMMI components could contain a data content.
The VEMMI objects includes all the objects used by most GUI:
The resources are elements which can be referenced by one or several VEMMI elements. They include:
VEMMI supports numerous data formats and is similar to Web regarding the variety and openness of supported datatypes. The VEMMI elements could have contents of various types:
As this in the case in Web world, numerous datatypes are supported but not in a mandatory way (for example JPEG pictures could be transmitted if the terminal VEMMI implementation supports this format). An interesting feature is that the information provider could check the datatypes supported by the terminal but also provide a specific data decoder to the user (on a floppy disk or on-line as required), or even use any proprietary datatype by supplying the appropriate decoder.
The main computer character sets are supported by VEMMI, including non-latin alphabets (Greek, Arabic, Cyrillic, Hebrew, Japanese, and so on...). Furthermore, VEMMI allows to switch from an alphabet to another one within a single text.
The text data used by the VEMMI application could be transmitted by the host server, but the application could use a local filename storing the text to display by specifying its filename.
VEMMI could display high quality text by specifying its character font, its colour its size and its attributes (italic, bold, underline). VEMMI text could includes sensible words whose activation will trigger any associated action.
In order to facilitate the interworking between VEMMI applications and existing Web services, HTML data may be displayed by VEMMI.
The main picture formats are supported:
Any other format could be represented by activating a viewer or decoder able to represent it.
In order to allow existing videotex services (mainly used in Europe) to evolve smoothly to multimedia, videotex screens could be represented by the VEMMI emulators in a standard videotex window. Either the videotex window or the VEMMI window could be active, allowing to keep the existing videotex databases and to upgrade some part of them to VEMMI applications.
Furthermore, existing videotex screens or data could be displayed in a graphical output area. Additionally to standard videotex data, photovideotex data may also be displayed, including fax data (as the T.4/T.6 fax encoding in included in photovideotex).
Sounds could be associated with a object and will be played during object activation (triggered by the application or the user action).
The sound formats supported are:
Video data could be displayed within a VEMMI object:
It is of course mandatory to have either a sufficient throughput or to have the video data stored on a local disk with high transfer rate.
VEMMI may be used for real-time applications. To the difference of MHEG-5, VEMMI has not been designed for real-time interactive video (mainly because the synchronization mechanisms provided by MHEG-5 are not included in VEMMI right now), but it could nevertheless be used in numerous real-time multimedia applications:
A metacode object contains VEMMI commands. It will not be displayed on the screen, but it will provides an easy way to avoid unnecessary dialogue steps with the host application and to improve the response time.
In many multimedia applications, large data must be displayed or used: pictures, sound, moving video, data, executable programs, and so on...
The transmission of these data may require a long time, even when medium speed networks as ISDN are used. VEMMI allows to use and display data already stored in the user personal computer, then avoiding both the transmission delay and the associated communication cost.
Several methods may be used:
The file transfer of files or VEMMI data offers the following facilities:
Additionnally to the VEMMI file transfer protocol, other standard protocols could be used, including:
In order to allow the VEMMI application to download files without having to know in advance the system configuration (disk unit names, directory names, and so on...), the server application may refer to directories using logical names that will be translated by the client software to their equivalent names on the personal computer. For example, an application may refer to the CD-ROM drive by the logical name $CD, and the VEMMI client software will translate it to the actual CD-ROM drive unit name (F:, H:,...) according to its configuration. The user has the ability to change the logical name definition and also to restrict the application access rights (read, write,...) or the available disk space for storage for a given application.
As it is understood that a given protocol could never plan for the introduction and support of all the features that may be needed thereafter, VEMMI has been designed to offer very open features allowing to extend it easily:
The program may already exists on the system, but it could also be downloaded by the host server during the first session and then stored on the system for future use.
VEMMI includes several optimization mechanisms designed to improve efficiency and response time, even when low or medium speed networks are used or if transit delays are encountered within the network (as it is often the case with Internet):
One of the main strong points of VEMMI is that its characteristics and features are quite complementary to those of the HTTP/HTML protocol used on the Web: VEMMI is then particularly useful to complement Web applications.
| Protocol | Tansport network | Characteristics | Advantages | Drawbacks | Well suited to |
| HTTP/HTML (Web) | TCP/IP | document-oriented, stateless and connectionless protocol, question/answer paradigm, the client software controls the session | document creation very easy, distributed applications, Web browsers widely spread worldwide | no real session nor context save, no real multiwindowing feature, the server could not send asynchronous data (not requested first) to the client | hyperdocuments consultation, simple interactives applications does not requiring object-oriented features |
| Java | TCP/IP | object-oriented language, the Java programs are downloaded to the client system and run locally | complex processing done locally by the client, object-oriented language with very extensive features | development is complex, does not run on Windows 3.x | improvement of Web services, local processing features, downloaded applications |
| VEMMI | TCP/IP, X.25/X29 and so on | client/server, object oriented protocol, the objects used by the client are created and managed by the remote host through a constant link between client and server. | client/server, object-orient environment, multi-windowing (of course), easy evolution from a standard data processing (telnet, videotex,...) application to a multimedia VEMMI application. | development is complex, client software still not widely available. | high-value added advanced applications requiring keeping a session context, multi-windowing and object oriented interface, the control of the client by the remote server. |
Table 1: Brief comparison of HTTP/HTML (Web), Java and VEMMI.
VEMMI is independent of the network and transport layers used, and could of course be used on Internet. Although several transport protocols could be used to transport VEMMI data on the Internet network (TCP, UDP,...), it is assumed that TCP will be mainly used.
The coding mechanism and client/server protocol used by VEMMI could be used on a TCP/IP stack, with the following remarks:
A VEMMI URL protocol scheme has then been designed (this document is currently an Internet-Draft in Last Call) and allows to integrate VEMMI services within Web services. Simultaneous navigation on the Web service and the VEMMI service is possible.
As most users well know, the HTTP communication protocol between a Web browser client and the server is very simple [8]: the client establishes a connection with the server and sends a request containing the word GET following with the name (partial URL) of the document to be retrieved. The server responds with the document contents and then closes immediately the session. The difference between the multimedia interactive VEMMI session maintaining the link between the client and the server and a session context during the communication and the stateless procedure used on the Web is immediately shown:
VEMMI, on the other hand, will run on a single continuous session between the client and server. Most of its characteristics are quite different from the Web (see below): for example VEMMI uses a client/server object-oriented interface.
| WWW Characteristics | Value | Advantages | Disadvantages |
| HTTP Protocol and Session Characteristics | Stateless protocol, based on a request/response paradigm: connect,
request, response, close.
There is no continuous session between client and server, but a new connection is established for every request. |
1) The server does not have to maintain a session context and an active
link with the client.
2) No need to maintain a continuous link on the network. 3) This also explains why it is so easy to access distributed documents stored on independent servers. |
1) As the server does not maintain a session context, the development
of complex, high-value added applications is very difficult.
2) Performance problems, both in the time taken for each connection, the slow start of the data transfer, and the load placed on both networks and servers. |
| Distributed document database | Yes, as the documents are independent (even linked) | Documents could point to other documents located anywhere, leading a wholly distributed worldwide database | Managing hyperlinks to remote documents that could be modified anytime and without notice at the remote location is tiresome. This explains why it is so often not possible to access to a document because the hyperlink became obsolete. |
| Object-oriented Man Machine Interface with advanced presentation features | No, the Web interface is document oriented. A single document is active. Even with the latest multi-document extension, the system remains a document-oriented one, not object-oriented. | Creation and update of HTML documents is very easy | 1) No real GUI object oriented interface.
2) HTML protocol is only document oriented. |
| Negociation of data representation | Yes | The supported data formats are specified by the client that could sort them according to its preference. | |
| Local processing facilities offered by the terminal | No (except Java or the other proprietary scripting mechanisms). | ||
| Entity controlling the session | The client controls the "session" and is responsible for
fetching and displaying the data.
In fact, there is no real session, as a Web "session" is composed of multiple independent HTTP requests (issued by the client) and responses (done by the server). |
The server could not react asynchronously. It could only send back its answer when a request arrive from the client. | |
| Well suited to | Hyperdocument consultation, simple transactional operations | ||
| Availability of tools | Yes | Numerous tools are not only widely available but often freeware. | |
| Worldwide acceptance | Yes |
Table 2: characteristics of the HTTP/HTML protocols used by the Web
As shown by the table 3 below, the VEMMI characteristics are quite opposite to those of HTTP. In that respect, we could see VEMMI and HTTP as complementary solutions, each one offering specific advantages and disadvantages and each best suited to some kind of applications.
| VEMMI Characteristics | Value | Advantages | Disadvantages |
| VEMMI Protocol and Session Characteristics | Client/server protocol supported by a continuous session between the client and the server. | The server could keep track of the user actions and maintains a session context. This allows to develop complex, high value added applications. | 1) The server must maintain a session context.
2) A network link (and the associated network load and communication costs) must be maintained between the client and the server. 3) Distributed databases are not easy to use. |
| Distributed document database | No | Complete data integrity as the VEMMI application does not rely on the availability of other systems or documents to run. | All the objects must be stored and managed on the server system. |
| Object-oriented Man Machine Interface with advanced presentation features | Yes, advanced Man-Machine Interface supporting wide range of objects and components. | 1) Advanced user interface conforming to those used on most GUI.
2) Objects and events- oriented programming. |
Implementing a VEMMI application is more complex than setting up a Web server. |
| Negociation of data representation | Yes | The server could check the datatypes supported by the terminal. | It is currently not possible to ponderate them according user preference. |
| Local processing facilities offered by the terminal | Yes (local actions, local object storage, metacode objects, operative objects). | 1) Improved response time
2) Activation of local programs 3) Possible local secure processing of data 4) Extension of the terminal and session capabilites |
|
| Entity controlling the session | Both client and server could interact asynchronously during the session, even if in most cases the session is mostly controlled by the client. | 1) Much advanced features for the application developer as the server could notify asynchronously the terminal when an event occur. For example a real-time messaging system between connected users is easy to do with VEMMI. | |
| Well suited to | Simple and complex multimedia applications requiring advanced object-oriented man-machine interface | ||
| Availability of tools | Not widely available right now, but numerous software suppliers are implementing VEMMI | ||
| Worldwide acceptance | Soon ? |
Table 3: characteristics of the VEMMI protocol: the comparison between the tables 2 and 3 demonstrates clearly the differences and the complementarity between VEMMI and Web
In order to take full advantage of the complementarity between VEMMI and Web, interworking mechanisms have been designed:
Standard HTML documents may include VEMMI hyperlink, that is URLs whose scheme is of VEMMI type, as specified in the VEMMI URL specification.
In this case, when the user selects a VEMMI URL when browsing the Web, the Web browser will activate the VEMMI client software, that will call the remote VEMMI host and establish the VEMMI session.
In order to support this feature, the user must have previously downloaded a VEMMI client software (this download may be proposed automatically by the Web server). Although VEMMI usage will spread more quickly when the existing Web browsers will have included for the support of VEMMI URLs and if they decide to bundle a VEMMI client software along their browsers, right now existing VEMMI client software could be downloaded on the Web and will interact with most browsers in order to manage VEMMI URLs.
VEMMI supports a multimedia area component allowing to display HTML documents and offering simultaneously the VEMMI interaction and the Web navigation facilities.
This support has been included within VEMMI for several technical reasons:
A multimedia area component will display HTML documents in a VEMMI dialog box, the user beeing able to simultaneously either navigate in Web mode using the HTML document hyperlinks, or the interact with other VEMMI components or objects. All the advantages offered by the object-oriented, event-driven, multi-windowing VEMMI user interface are kept, including:
The HTTP/HTML implementation in VEMMI offers the following facilities:
As demonstrated previously, the VEMMI protocol is complementary to the HTTP/HTML protocols used on the Web. Depending on the characteristics of the service to be created, an information provider could select either VEMMI, HTTP/HTML (with or without Java), or both. The table below helps to make such a choice.
| Service characteristics | Recommended protocol |
| Simple document retrieval with hyperlinks | HTTP/HTML |
| Retrieval of distributed documents stored on several differents systems | HTTP/HTML |
| Simple interactive services | HTTP/HTML or VEMMI |
| More complex interactive services | VEMMI |
| Multiwindowing object-oriented client/server interface | VEMMI |
| Local processing facilities | VEMMI or HTTP/HTML with Java |
| Asynchronous transmission of data from server to terminal (without a terminal prior request) | VEMMI (or Java in some cases) |
Table 4: Recommended protocols on Internet depending on the multimedia application characteristics
Thanks to the interoperability between Web and VEMMI, a single application may mix parts developed partly using the Web (HTTP/HTML), other parts using Java to download applets or programs, and other parts using VEMMI to interact on-line with a remote multimedia server.
As VEMMI is complementary to HTTP/HTML, a possible evolution seriously considered by several Internet actors is to extend the capabilities of the current Web browsers in order to simultaneously integrate in the same product a Web browser and a VEMMI client software.
But, even pending the availability of such software, several VEMMI client software already interwork with the major Web browsers (Netscape, all Mosaic based browsers,...), and be activated automatically to trigger a VEMMI multimedia interactive session when the user selects a VEMMI URL within a HTML document. Should the user does not have a VEMMI client software, the Web server may propose to download it automatically.
The aim of this presentation was to briefly present VEMMI to the main actors of the Internet world and to support the idea that VEMMI is a very useful complementary protocol to HTTP/HTML and Java and solves nearly all the problems currently hampering the development of some high-value added applications on Web, by offering an object-oriented interface, the multi-windowing fonction, the keeping of a session context, the ability for the server to react asynchronously (without a prior request from the client), and local storage and local processing features. The ability to interwork between VEMMI and Web applications is very important and will help to use the full potentialities of each protocol.
This presentation does not want to imply or promote the idea that VEMMI is better than the Web: in reality VEMMI offers different characteristics and features that could complement the Web, never replace it. As HTTP/HTML offers unmatched features (easiness of document creation, distributed documents, availability of tools, and so on...), VEMMI offers complementary characteristics (object-oriented interface, client/server protocol, keeping the session context, and so on...) that are suited to the development of specific advanced applications that could not be realized easily with the Web.
So, the spreading of VEMMI client and server software will help to create advanced multimedia applications that will complement the Web and help the development of the Internet.
Daniel Mavrakis (mavrakis@mctel.fr)
