Contemporary introduction.

William Overington

Tuesday 10 July 2001

Welcome to these documents about the designing and managing of a (particular) telesoftware channel to run upon the DVB-MHP platform (Digital Video Broadcasting - Multimedia Home Platform). Details of the DVB-MHP platform are available at the http://www.mhp.org website.

Telesoftware is the invention that produces a remote access computer system by means of the undirectional cyclic broadcasting of software without the need for a telephone line nor for any return information link to the central broadcasting computer.

One may think of the broadcasting system as providing a "slow access, read-only disc drive in the sky."

The DVB-MHP platform provides an excellent platform upon which to build a telesoftware channel and for it to be used in homes, schools and colleges throughout the world.

What does the word channel mean in this context? For a television channel the implication would be that a picture signal with accompanying sound, with meaningful content, would be broadcast every day of the year, for most, maybe all, of the 24 hours in each day.

For a telesoftware channel perhaps one might say that the implication would be that software would be broadcast every day of the year, for most, maybe all, of the 24 hours in each day.

Yet the implications of these two statements are vastly different in scale. The telesoftware channel could consist of perhaps as few as five programs that are available 24 hours each day for each day of the year.

If one telesoftware channel has 5 programs and another telesoftware channel has 200 programs, then how is that two channels when the one channel has much more software than the other? The answer is that of ownership and management of the channels.

So, it seems to me that many telesoftware channels, of varying sizes, could coexist quite happily in the DVB-MHP world. Quite how the carouselmaster of a broadcasting organization who has the task of arranging the broadcasting of a number of such channels will arrange the menu system so that end users may easily select from amongst these channels is a matter that will be interesting to consider. However, it might, with the cooperation of the manufacturers of the equipment of broadcasting systems, be possible to have a system whereby a carouselmaster at a broadcasting organization may give large channels their own place in the menu seen by end users and also add into the menu a place labeled as "Independent Channels" such that the end user, upon selecting "Independent Channels", will receive another menu which contains a list of these smaller channels, the broadcasting system equipment being designed so that these independent channels are seen as logically separate channels by the end user, notwithstanding that they are all configured as if part of one channel at the broadcasting end.

Now, I am not envisaging a situation whereby almost everyone can have a telesoftware channel that is broadcast throughout the world in a like manner to the way that almost everyone can have a web site on the internet. There are issues of bandwidth, regulation, quality and provenance.

However, I am suggesting that there might be a reasonable hope that a number of independent channels can flourish and be broadcast, either within one country or continent or throughout the world.

It is in this hope that I am setting forth on my quest to design and manage a telesoftware channel. I feel that if I can have at least, say, five programs available, accessible from their own menu, then it is reasonable to call it a channel. Certainly, I shall be hoping to have more than five programs available, with programs being added and retired from time to time. These documents are the story of my attempt to design and manage a telesoftware channel. This document is called "Contemporary introduction." because it is the introduction document available on the world wide web at the time of starting the project.

I have decided that I shall, at least to start, call this particular channel Astrolabe Channel as it is not the only possible telesoftware channel that may arise, from various sources. This means that the channel may become listed in lists of channels to run upon the DVB-MHP platform.

In the opening sentence of this document I use the word particular, enclosing it in parentheses. The reason for that is to make clear that these documents are not about designing and managing any telesoftware channel as a general practice, but are about designing and managing one particular telesoftware channel. This is because various factors involved in Astrolabe Channel may well be very different from some other telesoftware channels that may arise. For example, Astrolabe Channel will be totally "in the clear" and will not be a subscription channel. For example, Astrolabe Channel will have a strong emphasis on application software in the area of distance education. For example, the design and management of Astrolabe Channel will consider issues of whether it is possible, and if so under what circumstances, to have an access system so that, say, a distance education author using the computing facilities of a public library may construct a learning package and have the pleasure of his or her work being broadcast. For example, Astrolabe Channel is intended to be a superstation for world wide broadcasting rather than just in one country. This has implications for the writing of software applications. For example, if strings of text that are to be displayed on the screen are all defined in one particular polyglot compatibility section of a software application, then translation of the text in those strings to some other language will be possible by a linguist who need have no more than simple text editing knowledge of using a computer, rather than the translation task needing to be done by someone who is both a linguist and also a competent Java programmer. There would also be a time saving involved even if such a linguist-programmer could be found. It is hoped that the use of a polyglot compatibility section for defining strings will become a widespread practice in writing Java applications for the DVB-MHP platform, so that software will be translatable to other natural languages fairly easily. Naturally, there would be testing issues just in case a string in one language were a lot longer than in another language. Designing a Java program with a polyglot compatibility section may well also have other issues, such as making sure that one does not assume elsewhere in a Java program that a string of text defined in a polyglot compatibility section necessarily has the length that it has in the polyglot compatibility section. For example, suppose that a Java program is written so that screen dialogue is in English. A particular string might be called prompt1 and be 27 characters long. If, for whatever reason, later in the program, the programmer wishes to select the characters in the prompt1 string one at a time, then the programmer should first compute the length of the prompt1 string rather than assume that it is 27 characters long. This is because if, say, the program is later translated to have German screen dialogue, the German translation of the text in prompt1 may or may not be 27 characters long, yet the programmer must assume nothing.

Another issue would be trying to leave some space to the right of a string when displayed on the screen, in case the display of the string in another language is longer on the screen. Zero, one or more polyglot compatibility sections could appear in the source code of any Java program.

There is also the issue that it may be a lengthier task to program a Java program with a polyglot compatibility section. For example, use of a string such as "Please give the value of x." within a program just before the value of x is gathered may be quite self-explanatory. Use of a string called prompt1 is not so self-explanatory, even though the name of the string gives a clue. So the programmer might choose to add a line in the code after the use of prompt1 as follows.

// prompt1 in English is "Please give the value of x."

This all takes time. However, the taking of that time for a polyglot compatibility section is, I feel, a good practice and well worthwhile where there is any possibility of a program being used in other than the screen language for which it was first written.

Each polyglot compatibility section could be enclosed within comments as follows.

// polyglot compatibility section starts

// polyglot compatibility section finishes

Here is an example for defining three strings.

// polyglot compatibility section starts
    String prompt1="Please give the value of x.";
    String prompt2="Please give the value of y.";
    String report1="The value of z is ";
// polyglot compatibility section finishes

A linguist wishing to translate the screen dialogue from English to another language simply needs to search through the source code of the Java program for the word "polyglot" and then translate the English text within all of the strings within each of the polyglot compatibility sections that are found.

Certainly, the Java program would need to be compiled and tested to ensure that text does not overlap other sections of the display, and if it does, maybe a programmer would need to take some remedial action on the software. However, even then, there would be a time saving in the whole process as the translation of the strings would have been carried out independently.

Part of this project is to try to design guidelines for programming for straightforward porting from one natural language to another.

A key issue is as to just what facilities Astrolabe Channel needs in order to be "on air" and how Astrolabe Channel is to be financed.

My present thinking is that Astrolabe Channel will not need its own broadcasting equipment and would be broadcast as but one of a number of channels by a broadcasting organization that has all of the facilities itself. So the question becomes one of how the broadcasting organization would receive the information for Astrolabe Channel and load it into the broadcaster's broadcasting computer; together with the question of the terms upon which any broadcaster might be willing to carry Astrolabe Channel. For example, would the broadcaster wish me to pay money to the broadcaster so that the broadcaster would broadcast Astrolabe Channel, or would the broadcaster wish to pay money to me for the benefit of having Astrolabe Channel as part of the channels that the broadcaster makes available, or would the broadcaster wish to have a situation where the broadcaster receives Astrolabe Channel and puts it on air and neither the broadcaster pays me money nor I pay the broadcaster money? This could perhaps vary from country to country.

A related question is as to whether Astrolabe Channel will carry advertising or sponsorship acknowledgements. If it does, then will there be businesses willing to spend money advertising on Astrolabe Channel or sponsoring it? Astrolabe Channel may well be willing to accept advertising and sponsorship if it is forthcoming.

Suppose that there is advertising and sponsorship available. Would advertising be added on a global basis or would it be designed so that advertising content could be added locally by the carouselmaster of each broadcasting organization?

An interesting aspect of the Java system that is used by the DVB-MHP platform is that it uses unicode. Details of unicode are available at the http://www.unicode.org website.

An interesting feature is the availibility within the unicode system of the private use area. My intention is that Astrolabe Channel will use a special character set called eutocode that uses some of the codes of the private use area in a defined manner so as to produce additional on-screen effects. For example, the use of eutocode codes to provide graphics directly embedded within files of unicode plain text, both vector graphics and scan graphics being possible. A Java program running on Astrolabe Channel that uses unicode files could be designed such that where codes in the private use area of unicode are encountered then they will be interpreted as being codes from the eutocode system. The eutocode system is only in the early stages of definition and so can have facilities added as the project proceeds. As a eutocode handler would be broadcast as part of Astrolabe Channel rather than being built into the hardware of the end user's DVB-MHP terminal, as updates are made to the eutocode system, an updated eutocode handler may be incorporated into the software being broadcast on Astrolabe Channel.

There are various matters about which I need to learn in order to be able to get Astrolabe Channel implemented. Some of these concern programming. The first issue that I need to address is exactly how one programs a Java application to run on a DVB-MHP platform. I know some of the basics about Java. My main use of Java has been to program Java applets for use in this webspace. I need to find out the specifics of how to program Java content for the DVB-MHP platform. How does it differ from programming an applet for use on the world wide web? Can I find an example somewhere? The above would be just to get a "Hello world" message onto a DVB-MHP terminal display. I could get some way with that, but once I need to get interactivity between the program and the user, there are then further matters about which I need to learn. For example, how does one program a Java program that is to run on the DVB-MHP platform to accept button pushes from the buttons on an infrared remote control device. I have programmed, for the world wide web, a Java applet that has four buttons, with these buttons appearing within the display area of the applet, and the user gets interactivity by clicking on these on-screen graphic buttons with a mouse unit. That is different from coloured buttons on a hand held infra-red remote control unit. Just exactly how does my Java program need to be altered? That then raises the issue of how I may test that the DVB-MHP program works with the remote control. What equipment do I need to get?

As telesoftware does not use a telephone line nor need any return link to the central broadcasting computer, a telesoftware channel is as accessible as any one-way broadcast channel, there being no speed load on the central broadcasting computer as additional DVB-MHP terminals are added in the reception region. A user is effectively using a computer with a slow access, read-only disc drive attached. The content of this telesoftware disc may change from time to time, either by the action of the carouselmaster at the central broadcasting computer or by automated updating of software and data files. For example, weekly changes for lessons in a ten week distance education course. Interesting questions are just what is the typical capacity of an object carousel of a DVB-MHP system, and how much of that capacity could I reasonably design Astrolabe Channel to occupy at any one time? Even then, can the DVB-MHP broadcasting system be configured such that, say, Astrolabe Channel could have so many Megabytes accessible within so many seconds and a lot more Megabytes accessible within ten times as long, by broadcasting some packages at every cycle of the object carousel and some every tenth cycle?

There is much for me to learn in this project. As one problem is resolved, others emerge. The project to design and manage Astrolabe Channel proceeds.

Astrolabe Channel

This file is accessible as follows.

http://www.users.globalnet.co.uk/~ngo/ast00100.htm