System and process for object rendering on thin client platforms5987256Abstract A system for processing an object specified by an object specifying language such as HTML, JAVA or other languages relying on relative positioning, that require a rendering program utilizing a minimum set of resources, translates the code for use in a target device that has limited processing resources unsuited for storage and execution of the HTML rendering program, JAVA virtual machine, or other rendering engine for the standard. Data concerning such an object is generated by a process that includes first receiving a data set specifying the object according to the object specifying language, translating the first data set into a second data set in an intermediate object language adapted for a second rendering program suitable for rendering by the target device that utilizes actual target display coordinates. The second data set is stored in a machine readable storage device, for later retrieval and execution by the thin client platform. Claims What is claimed is: Description COPYRIGHT DISCLAIMER
TABLE 1
__________________________________________________________________________
Copyright EnReach 1997
__________________________________________________________________________
function convert.sub.-- html (input : pointer) : chtmlfile;
// this takes a pointer to an HTML file and translates it into a CHTML
binary file
begin
deviceInfo := LoadDeviceInfo( );
// Loads size and colors of target device
Parse HTML file // use a parser to break the HTML file up into
// tags represented in a fashion suitable for display
For each HTML tag (<IMG . . . > = 1 tag, <P> a paragraph </P> = 1 tag),
select a sequence of CHTML instructions to render the tag on the output
device.
As instructions are selected, colors and positioning are optimized based
on the
device size and palette.
CHTML instructions include:
TITLE string
TEXT formatted text at a specific position,
complex formatting will
require multiple CHTML TEXT instructions
IMAGE image information including image-map,
animation info, image data
ANCHOR HTML reference
Basic geometric instructions such as: SQUARE, FILLEDSQUARE, CIRCLE,
FILLEDCIRCLE, and LINE, permit the complex rendering required by some
HTML instructions to be decomposed into basic drawing instructions. For
example, the bullets in front of lists can be described in CHTML
instructions
as squares and circles at specific locations.
CHTML instructions including TEXT and IMAGE instructions can be
contained within anchors. The CHTML compiler must properly code all
instructions to indicate if an instruction is contained in an anchor.
The CHTML instructions can then be written to the output file along with
some header
information.
end;
__________________________________________________________________________
Table 2 sets forth the data structure for the precompiling process.
TABLE 2
__________________________________________________________________________
Copyright EnReach 1997
__________________________________________________________________________
/* HTML font structure */
typedef struct tagHTMLFont
char name[64];
int size;
int bold;
int italic;
int underline;
int strikeout;
} HTMLFont;
/* FG point structure */
typedef struct tagFGPoint
{
int fX;
int fY;
} FGPoint;
/* FG rectangle structure */
typedef struct tagFGRect
{
int fLeft;
int fTop;
int fRight;
int fBottom;
} FGRect;
/* html node types, used by hType attribute in HTML.sub.-- InfoHead
structure */
#define HTML.sub.-- TYPE.sub.-- TITLE 0
/* title of the html page */
#define HTML.sub.-- TYPE.sub.-- TEXT 1
/* text node */
#define HTML.sub.-- TYPE.sub.-- CHINESE 2
/* chinese text node */
#define HTML.sub.-- TYPE.sub.-- IMAGE 3
/* image node */
#define HTML.sub.-- TYPE.sub.-- SQUARE 4
/* square frame */
#define HTML.sub.-- TYPE.sub.-- FILLEDSQUARE 5
/* filled square */
#define HTML.sub.-- TYPE.sub.-- CIRCLE 6
/* circle frame */
#define HTML.sub.-- TYPE.sub.-- FILLEDCIRCLE 7
/* filled circle */
#define HTML.sub.-- TYPE.sub.-- LINE 8
/* line */
#define HTML.sub.-- TYPE.sub.-- ANCHOR 9
/* anchor node */
#define HTML.sub.-- TYPE.sub.-- ANIMATION 10
/* animation node */
#define HTML.sub.-- TYPE.sub.-- MAPAREA 11
/* client side image map area node */
/* header info of compiled html file */
typedef struct tagHTML.sub.-- FileHead
{
unsigned int fBgColor;
/* background color index */
unsigned int fPaletteSize;
/* size of palette */
} HTML.sub.-- FileHead;
/* header info of each html node */
typedef struct tagHTML.sub.-- InfoHead
{
unsigned int hType; /* type of the node */
unsigned int hSize; /* size of htmlInfo */
} HTML.sub.-- InfoHead;
/* html info structure */
typedef struct tagHTML.sub.-- Info
{
HTML.sub.-- InfoHead htmlHead;
/* header info */
unsigned char htmlInfo[1];
/* info of the html node */
} HTML.sub.-- Info;
/* html title structure */
typedef struct tagHTML.sub.-- Title
{
unsigned int textLen;
/* length of text buffer */
char textBuffer[1]; /* content of text buffer */
} HTML.sub.-- Title;
/* html text structure */
typedef struct tagHTML.sub.-- Text
{
FGPoint dispPos; /* display coordinates */
int anchorID; /* anchor id if it's inside an anchor, -1 if not */
HTMLFont textFont; /* font of the text */
unsigned int textColor;
/* color index of the text */
unsigned int textLen;
/* length of text buffer */
char textBuffer[1]; /* content of text buffer */
} HTML.sub.-- Text
/* html chinese structure */
typedef struct tagHTML.sub.-- Chinese
{
FGPNT dispPos; /* display coordinates */
int anchorID; /* anchor id if it's inside an anchor, -1 if not */
unsigned int textColor;
/* color index of the text */
unsigned int bufLen;
/* length of the bitmap buffer (16* 16) */
char textBuffer[1]; /* content of text buffer */
} HTML.sub.-- Chinese;
/* html image structure */
typedef struct tagHTML.sub.-- Image
{
FGRect dispPos; /* display coordinates */
int anchorID; /* anchor id if it's inside an anchor, -1 if not */
int animationID; /* animation id if it supports animation, -1 if not */
int animationDelay; /* delay time for animation */
char mapName[64];
/* name of client side image map, empty if no
image map */
void *data; /* used to store image
data */
unsigned int fnameLen;
/* length of the image file name */
char fname[1]; /* image filename */
} HTML.sub.-- Image;
/* square structure */
typedef strnct tagHTML.sub.-- Square
{
FGRect dispPos; /* display coordinates */
unsigned int borderColor; /* border color index */
} HTML.sub.-- Square;
/* filled square structure */
typedef struct tagHTML.sub.-- FilledSquare
{
FGRect dispPos; /* display coordinates */
unsigned int brushColor; /* the inside color index */
} HTML.sub.-- FilledSquare;
/* circle structure */
typedef struct tagHTML.sub.-- Circle
{
FGRect dispPos; /* display coordinates */
unsigned int borderColor; /* border color index */
} HTML.sub.-- Circle
/* circle structure */
typedef struct tagHTML.sub.-- FilledCircle
{
FGRect dispPos; /* display coordinates */
unsigned int brushColor; /* the inside color index */
} HTML.sub.-- FilledCircle;
/* line structure */
typedef struct tagHTML.sub.-- Line
{
FGPoint startPos; /* line starting position */
FGPoint endPos; /* line end position */
int style; /* style of the line (solid, dashed, dotted,
etc.) */
unsigned int penColor;
/* pen color index */
} HTML.sub.-- Line;
/* anchor structure */
typedef struct tagHTML.sub.-- Anchor
{
int anchorID; /* id of the anchor */
unsigned int hrefLen;.
/* length of href */
char href[1]; /* url of the anchor */
} HTML.sub.-- Anchor;
/* animation structure */
typedef struct tagHTML.sub.-- Animation
{
int animationID; /* id of the animation */
unsigned int frameTotal; /* total number of animation frames */
long runtime; /* animation runtime */
} HTML.sub.-- Animation;
#define SHAPE.sub.-- RECTANGLE 0
#define SHAPE.sub.-- CIRCLE 1
#define SHAPE.sub.-- POLY 2
/* image map area structure */
typedef struct tagHTML.sub.-- MapArea
{
char mapName[64]; /* name of client side image map
*/
intshape; /* shape of the area */
int numVer; /* number of vertix */
int coords[6][2];
/* coordinates */
unsigned int hrefLen;
/* length of href */
char href[1]; /* url the area pointed to */
} HTML.sub.-- MapArea;
__________________________________________________________________________
An example routine for reading this file into the thin platform memory follows in Table 3.
TABLE 3
__________________________________________________________________________
Copyright EnReach 1997
__________________________________________________________________________
reading this file:
#define BLOCK.sub.-- SIZE 256
/* returns number of nodes */
long read.sub.-- chm(const char *filename,
/* input: .chm file name */
HTML.sub.-- Info ***ppNodeList, /* output: array of (HTML.sub.-- Info *)
including anchors. */
YUVQUAD **ppPalette, /* output: page palette */
unsigned int *palette.sub.-- size)
/* output: palette size */
int fd;
char head[12];
long total.sub.-- nodes = 0;
long max.sub.-- nodes = 0;
HTML.sub.-- FileHead myFileHead;
HTML.sub.-- InfoHead myInfoHead;
HTML.sub.-- Info *pNodeInfo;
void *pNodeData;
long i;
HTML.sub.-- InfoHead *pHead;
if (!ppNodeList .parallel. !ppPalette .parallel. !palette.sub.-- size)
return 0;
(*ppNodeList) = NULL;
(*ppPalette) = NULL;
(*palette.sub.-- size) = 0
/* open file */
fd = .sub.-- open(filename,.sub.-- O.sub.-- BINARY.vertline..sub.--
O.sub.-- RDONLY);
if(fd < 0)
return 0;
/* read header and check for file type */
if (.sub.-- read(fd, head, 10) != 10)
{
.sub.-- close(fd);
return 0;
}
if (strncmp(head, "<COMPHTML>", 10))
{
.sub.-- close(fd);
return 0;
}
/* read file header */
if(.sub.-- read(fd, &myFileHead, sizeof(HTML.sub.-- FileHead)) !=
sizeof(HTML.sub.-- FileHead))
{
.sub.-- close(fd);
return 0;
}
(*palette.sub.-- size) = myFileHead.fpaletteSize;
/* read the palette */
if ((*palette.sub.-- size) > 0)
{
(*ppPalette) = (YUVQUAD *)malloc(sizeof(YUVQUAD)*
(*palette.sub.-- size));
if (.sub.-- read(fd, (*ppPalette), sizeof(YUVQUAD) * (*palette.sub.--
size))
!= (int) (sizeof(YUVQUAD) * (*palette.sub.-- size)))
{
.sub.-- close(fd);
return 0;
}
}
/* read anchors along with other html nodes */
while (1)
{
if (.sub.-- read(fd, &myInfoHead, sizeof(HTML.sub.-- InfoHead))
!= sizeof(HTML.sub.-- InfoHead))
{
break;
}
if (myInfoHead.hSize > 0)
{
pNodeInfo = (HTML.sub.-- Info *) malloc(myInfoHead.hSize +
sizeof(HTML.sub.-- InfoHead));
if (!pNodeInfo)
break;
memcpy(pNodeInfo, &myInfoHead,
sizeof(HTML.sub.-- InfoHead));
if (.sub.-- read(fd, &pNodeInfo[sizeof(HTML.sub.-- InfoHead)],
myInfoHead.hSize)
!= (int)myInfoHead.hSize)
{
break;
}
/* check if we need to do memory allocation */
if (total.sub.-- nodes >= max.sub.-- nodes)
{
if(!max.sub.-- nodes)
{
/* no node in the list yet */
(*ppNodeList) = (HTML.sub.-- Info **)
malloc(
sizeof(HTML.sub.-- Info *)*
BLOCK.sub.-- SIZE);
}
else
{
(*ppNodeList) = (HTML.sub.-- Info **)
realloc((*ppNodeList),
max.sub.-- nodes + sizeof(HTML.sub.-- Info
*) * BLOCK.sub.-- SIZE);
}
if (!(*ppNodeList))
break;
max.sub.-- nodes += BLOCK.sub.-- SIZE;
}
(*ppNodeList)[total.sub.-- nodes] = pNodeInfo;
total.sub.-- nodes++;
}
}
.sub.-- close(fd);
/* test our data */
for (i = 0; i < total.sub.-- nodes; i++)
{
pNodeInfo = (*ppNodeList)[i];
pHead = (HTML.sub.-- InfoHead *) pNodeInfo;
pNodeData = pNodeInfo + sizeof(HTML.sub.-- InfoHead);
if(pHead->hType == HTML.sub.-- TYPE.sub.-- TEXT)
{
HTML.sub.-- Text *pText = (HTML.sub.-- Text *) pNodeData;
}
else if(pHead->hType == HTML.sub.-- TYPE.sub.-- IMAGE)
{
HTML.sub.-- Image *pImage = (HTML.sub.-- Image *) pNodeData;
if (pImage->fnameLen > 0)
{
/* load the image file */
pImage->data = load.sub.-- ybm(pImage->fname);
}
}
else if (pHead->hType == HTML.sub.-- TYPE.sub.-- ANCHOR)
{
HTML.sub.-- Anchor *pAnchor = (HTML.sub.-- Anchor *)
pNodeData;
}
else if(pHead->hType == HTML.sub.-- TYPE.sub.-- ANIMATION)
{
HTML.sub.-- Animation *pAnimation = (HTML.sub.-- Animation *)
pNodeData;
}
else if(pHead->hType == HTML.sub.-- TYPE.sub.-- MAPAREA)
{
HTML.sub.-- MapArea *pMapArea = (HTML.sub.-- MapArea *)
pNodeData;
}
else if (pHead->hType == HTML.sub.-- TYPE.sub.-- LINE)
{
HTML.sub.-- Line *pLine = (HTML.sub.-- Line *) pNodeData;
}
else if(1)Head->hType == HTML.sub.-- TYPE.sub.-- SQUARE)
{
HTML.sub.-- Square *pSquare = (HTML.sub.-- Square *) pNodeData;
}
else if(pHead->hType == HTML.sub.-- TYPE.sub.-- CIRCLE)
{
HTML.sub.-- Circle *pCircle = (HTML.sub.-- Circle *) pNodeData;
}
else if (pHead->hType == HTML.sub.-- TYPE.sub.-- FILLEDSQUARE)
{
HTML.sub.-- FilledSquare *pFilledSquare =
(HTML.sub.-- FilledSquare *) pNodeData;
}
else if (pHead->hType == HTML.sub.-- TYPE.sub.-- FILLEDCIRCLE)
{
HTML.sub.-- FilledCircle *pFilledCircle = (HTML.sub.-- FilledCirc
le
*) pNodeData;
}
else if(pHead->hType == HTML.sub.-- TYPE.sub.-- TITLE)
{
HTML.sub.-- Title *pTitle = (HTML.sub.-- Title *) pNodeData;
}
}
return total.sub.-- nodes;
}
__________________________________________________________________________
The compiled HTML file structure is set forth in FIG. 7 as described in Table 2. The file structure begins with a ten character string COMPHTML 900. This string is followed by a HTML file header structure 901. After the file header structure, a YUV color palette is set forth in the structure 902 this consists of an array of YUVQUAD values for the target device. After the palette array, a list 903 of HTML information structures follows. Usually the first HTML information structure 904 consists of a title. Next, a refresh element typically follows at point 905. This is optional. Next in the line is a background color and background images if they are used in this image. After that, a list of display elements is provided in proper order. The anchor node for the HTML file is always in front of the nodes that it contains. An animation node is always right before the animation image frames start. The image area nodes usually appear at the head of the list. The HTML file header structure includes a first value BgColor at point 906 followed by palette size parameters for the target device at point 907. The YUVQUAD values in the color palette consist of a four word structure specifying the Y, U, and V values for the particular pixel at points 908-910. The HTML information structures in the list 903 consist of a type field 911, a size field 912, and the information which supports the type at field 913. The type structures can be a HTML.sub.-- Title, HTML.sub.-- Text, HTML.sub.-- Chinese, HTML.sub.-- Xxge, HTML.sub.-- Square, HTML.sub.-- FilledSquare, HTML.sub.-- Circle, HTML.sub.-- FilledCircle, HTML.sub.-- Line, HTML.sub.-- Author, HTML.sub.-- Animation, . . . Functions that would enable a thin platform to support viewing of HTML-based content pre-compiled according to the present invention includes the following: General graphics functions int DrawPoint (int x, int y, COLOR color, MODE mode); int DrawLine (int x1, int y1, int x2, int y2, COLOR color, MODE mode); int DrawRectangle(int x1, int y1, int x2, int y2, COLOR color, MODE mode); int FillRectangle(int x1, int y1, int x2, int y2, COLOR color, MODE mode); int ClearScreen(COLOR color); Color palette int ChangeYUVColorPalette(); Bitmap function int BitBlt(int dst.sub.-- x1, int dst.sub.-- y1, int dst.sub.-- x2, int dst.sub.-- y2, unsigned char *bitmap, MODE mode); String drawing functions int GetStringWidth(char *str, int len); int GetStringHeight(char *str, int len); int DrawStringOnScreen(int x, int y, char *str, int len, COLOR color, MODE mode); Explanation All (x, y) coordinates are based on the screen resolution of the target display device (e.g. 320.times.240 pixels). COLOR is specified as an index to a palette. MODE defines how new pixels replace currently displayed pixels (COPY, XOR, OR, AND). Minimum support for DrawLine is a horizontal or vertical straight line, although it would be nice to have support for diagonal lines. The ChangeYUVColorPalette function is used for every page. BitBlt uses (x1, y1) and (x2, y2) for scaling but it is not a requirement to have this scaling functionality. String functions are used for English text output only. Bitmaps are used for Chinese characters. FIGS. 8A and 8B set forth the run time engine suitable for execution on a thin client platform for display of the compiled HTML material which includes the function outlined above in the "display" step 1220 of FIG. 8B. The process of FIG. 8A starts at block 1000. The ran time engine is initialized on the client platform by loading the appropriate elements of the run time engine and other processes known in the art (step 1010). The next step involves identifying the position of the file, such as on the source CD or other location from which the file is to be retrieved and setting a flag (step 1020). The flag is tested at step 1030. If the flag is not set, then the algorithm branches to block 1040 at which the flag is tested to determine whether it is -1 or not. If the flag is -1, then the algorithm determines that a system error has occurred (step 1050) and the process ends at step 1060. If the flag at step 1040 is not -1, then the file has not been found (step 1070). Thus after step 1070 the algorithm returns to step 1020 to find the next file or retry. If at step 1030, the flag is set to 1 indicating that the file was found, then the content of the file is retrieved using a program like that in Table 3, and it is stored at a specified address. A flag is returned if this process succeeds set equal to 1 otherwise it is set equal to 0 (step 1080). Next the flag is tested (step 1090). If the flag is not equal to 1 then reading of the file failed (step 1100). The process then returns to step 1020 to find the next file or retry. If the flag is set to 1, indicating that the file has been successfully loaded into the dynamic RAM of the target device, then the "Surf.sub.-- HTML" process is executed (step 1110). The details of this process are illustrated in FIG. 8B. Next the current page URL name is updated according to the HTML process (step 1120). After updating the current URL name, the process returns to step 1020 to find the next file. FIG. 8B illustrates the "Surf.sub.-- HTML" process of step 1110 in FIG. 8A. This process starts at point 1200. The first part is initialization step 1210. A display routine is executed at step 1220 having the fixed coordinate functions of the precompiled HTML data set. First, the process determines whether applets are included in the file (step 1230). If they are included, then the applet is executed (step 1240). If no applets are included or after execution of the applet, then a refresh flag is tested (step 1240). If the flag is equal to 1, then it is tested whether a timeout has occurred (step 1250). If a timeout has occurred, then the current page is updated (step 1260) and the process returns set 1210 of FIG. 8B, for example. If at block 1240 the refresh flag was not equal to 1, or at block 1250 the timeout had not expired, then the process proceeds to step 1270 to get a user supplied input code such as an infrared input signal provided by a remote control at the target device code. In response to the code, a variety of process are executed as suits a particular target platform to handle the user inputs (step 1280). The process returns a GO.sub.-- HOME, or a PLAY.sub.-- URL command, for example, which result in returning the user to a home web page or to a current URL, respectively. Alternatively the process loops to step 1270 for a next input code. As mentioned above, FIG. 4 illustrates the JAVA precompiler according to the present invention. The JAVA precompiler receives standard full feature JAVA byte codes as input on line 600. Byte codes are parsed at block 601. A JAVA class loader is then executed at block 602. The classes are loaded into a command module 603 which coordinates operations of a JAVA virtual machine 604, a JAVA garbage collection module 605, and a JAVA objects memory mapping optimizing engine 606. The output is applied by block 607 which consists of a compiled JAVA bytecode format according to the present invention. The process is illustrated in FIG. 9 beginning at block 1500. First the JAVA bytecode file is loaded (block 1510). Next, the JAVA classes are loaded based on the interpretation of the bytecode (step 1520). Next the classes are optimized at step 1530. After optimizing the classes, the byte codes are translated to a reduced bytecode (step 1540). Finally the reduced bytecode is supplied (step 1550) and the algorithm stops at step 1560. Basically the process receives a JAVA source code file which usually has the format of a text file with the extension JAVA. The JAVA compiler includes a JAVA virtual machine plus compiler classes such as SUN.TOOLS.JAVAC which are commercially available from Sun Micro Systems. The JAVA class file is parsed which typically consists of byte codes with the extension .CLASS. A class loader consists of a parser and bytecode verifier and processes other class files. The class structures are processed according to the JAVA virtual machine specification, such as the constant pool, the method tables, and the like. An interpreter and compiler are then executed. The JAVA virtual machine executes byte codes in methods and outputs compiled JAVA class files starting with "Main". The process of loading and verifying classes involves first finding a class. If the class is already loaded a read pointer to the class is returned, if not, the class is found from the user specified class path or directory, in this case a flash memory chunk. After finding the class, the next step is executed. This involves loading the bytes from the class file. Next, class file bytes are put into a class structure suitable for run time use, as defined by the JAVA virtual machine specification. The process recursively loads and links the class to its super classes. Various checks and initializations are executed to verify and prepare the routine for execution. Next, initialization is executed for the method of the class. First the process ensures that all the super classes are initialized, and then cause the initialization method for the class. Finally, the class is resolved by resolving a constant pool entry the first time it is encountered. A method is executed with the interpreter and compiler by finding the method. The method may be in the current class, its super class or other classes as specified. A frame is created for the method, including a stack, local variables and a program counter. The process starts executing the bytecode instructions. The instructions can be stack operations, branch statements, loading/storing values, from/to the local variables or constant pool items, or invoking other methods. When an invoked method is a native function, the implemented platform dependent function is executed. In FIG. 9A, the process of translating JAVA byte codes into compiled byte codes (step 1504 of FIG. 9) is illustrated. According to the process FIG. 9A, the high level class byte codes are parsed from the sequence. For example, Windows dialog functions are found (1570). The high level class is replaced with its lower level classes (1580). This process is repeated until all the classes in the file become basic classes (1590). After this process, all the high level functions have been replaced by lower level level basic functions, such as draw a line, etc. (1600). JAVA byte codes in classes include a number of high level object specifying functions such as a window drawing function and other tool sets. According to the present invention, these classes are rendered by the precompiler into a set of specific coordinate functions such as those outlined above in connection with the HTML precompiler. By precompiling the object specifying functions of the JAVA byte code data set, significant processing resources are freed up on the thin client platform for executing the other programs carried in a JAVA byte code file. Furthermore, the amount of memory required to store the run time engine and JAVA class file for the thin client platform according to the present invention which is suitable for running a JAVA byte code file is substantially reduced. FIG. 10 illustrates one environment in which use of the present invention is advantageous. In particular, in the Internet environment a wide variety of platforms are implemented. For example, an end user workstation platform 100 is coupled to the Internet 101. An Internet server platform 102 is also coupled to the Internet 101 and includes storage for JAVA data sets, HTML data sets, and other image files. A server 103 with an intermediate compiler according to the present invention for one or more of the data sets available in the Internet is coupled to the Internet 101 as well. A variety of "thin" platforms are also coupled to the Internet and/or the server 103. For example, an end user thin platform A 104 is coupled to the server 103. End user thin platform B 105 is coupled to the server 103 and to the Internet 101. End user thin platform C 106 is coupled to the Internet 101 and via the Internet all the other platforms in the network. A variety of scenarios are thus instituted. The source of data sets for end user platform C 106 consists of the World Wide Web. When it requests a file from server 102, the file is first transferred to the intermediate compiler at server 103, and from server 103 to the end user platform 106. End user platform A 104 is coupled directly to the server 103. When it makes a request for a file, the request is transmitted to the server 103, which retrieves the file from its source at server 102, translates it to the compiled version and sends it to platform A 104. End user platform B is coupled to both the server 103 and to the Internet 101. Thus, it is capable of requesting files directly from server 102. The server 102 transmits the file to server 103 from which the translated compiled version is sent to platform B 105. Alternatively, platform B may request a file directly from server 103 which performs all retrieval and processing functions on behalf of platform B. FIG. 11 illustrates an alternative environment for the present invention. For example, the Internet 120 and an Intranet 121 are connected together. A server 122 is coupled to the Intranet 121 and the Internet 120. The server 122 includes the HTML and JAVA intermediate compiling engines according to the present invention as represented by block 123. The server 122 acts as a source of precompiled data sets for thin client platforms 124, 125 and 126 each of which has a simplified run time engine suitable for the compiled data sets. Thus the powerful HTML/JAVA engine resides on the network server 122. The thin network computers 124, 125, 126 are connected to the server have only the simplified run time engine for the compiled image set. Thus, very small computing power is required for executing the display. Thus computing tasks are done using the network server, but displayed on a thin network computer terminals 124-126. FIGS. 12A and 12B illustrate the off-line environment for use of the present invention. In FIG. 12A, the production of the compiled files is illustrated. Thus, a standard object file, such as an HTML or JAVA image, is input online 1300 to a compiler 1301 which runs on a standard computer 1302. The output of the compiler on line 1303 is the compiled bitmap, compiled HTML or compiled JAVA formatted file. This file is then saved on a non-volatile storage medium such as a compact disk, video compact disk or other storage medium represented by the disk 1304. FIG. 12B illustrates the reading of the data from the disk 1304 and a thin client such as a VCD box, a DVD box or a set top box 1305. The run time engine 1306 for the compiled data is provided on the thin platform 1305. Thus, off-line fill feature HTML and JAVA processing is provided for a run time environment on a very thin client such as a VCD/DVD player. The standard HTML/JAVA objects are pre-processed and compiled into the compiled format using the compiler engine 1301 on a more powerful computer 1302. The compiled files are saved on a storage medium such as a floppy disk, hard drive, a CD-ROM, a VCD, or a DVD disk. A small compiled run time engine is embedded or loaded into the thin client device. The run time engine is used to play the compiled files. This enables use of a very small client for running full feature HTML and JAVA programs. Thus, the machine can be used in both online, and off-line modes, or in a hybrid mode. The foregoing description of a preferred embodiment of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Obviously, many modifications and variations will be apparent to practitioners skilled in this art. It is intended that the scope of the invention be defined by the following claims and their equivalents.
|
Same subclass Same class Consider this |
||||||||||