A method and apparatus for the compilation of an interpretative language for interactive television

ES 2 559 638 T3

DESCRIPTION

Method and equipment for the compilation of an interpretive language for interactive television

Copyright notice

[0001] A part of the disclosure of this patent document contains material (code lists and message lists) on which the claim of copyright protection is made.

The copyright owner has no objection to any person's facsimile reproduction of the patent document or patent disclosure as it appears in the US Patent and Trademark Office document or registration, but reserves any other rights.

Copyright 2001 OpenTV, Inc.

Background of the invention

Field of the invention

[0002] The present invention relates to the field of displaying interactive television content and specifically to the extraction of an interpretive language, for example JavaScript from text markup language, for example HTLM pages and compiling the JavaScript to a server for downloading and to a client device for execution on the content display provided by a broadcaster, the Internet or memory in an interactive television display space.

Summary of Related Art

[0003] Interactive television systems can be used to provide a wide variety of services to viewers.

Interactive television systems are capable of delivering typical video program streams, interactive television applications, text and graphic images, web pages, and other types of information.

Interactive television systems are also capable of recording viewer actions or responses and can be used for such purposes as marketing, entertainment, and education.

Users or viewers can interact with the systems by requesting advertised products or services, competing against participants in a television contest, requesting specialized information in relation to particular programs, or browsing through information pages.

[0004] Typically, a broadcasting service provider or network controller generates an interactive television signal for transmission to a viewer's television.

The interactive television signal may include an interactive part consisting of application code or control information, as well as an audio / video part consisting of a television program or other informational monitors.

The broadcast service provider combines the audio / video and interactive parts into a single signal for transmission to a receiver connected to the user's television.

The signal is generally compressed before transmission and transmitted through typical broadcast channels, such as cable television (CATV) lines or direct satellite transmission systems.

[0005] Typically, a set-top box connected to the television controls the interactive functionality of the television.

The decoder receives a broadcast signal transmitted by the broadcasting service provider, separates the interactive part from the audio-video part and decompresses the respective parts of the signal.

The set-top box uses the interactive information, for example, to run an application while the audio / video information is transmitted to the television.

The set-top box can combine the audio / video information with interactive graphics or audio generated by the interactive application prior to transmission of the information to the television.

Interactive graphics and audio can present additional information to the viewer or can trigger the viewer for contribution.

The set-top box may provide viewer contribution or other information to the broadcast service provider via a cable or modem connection.

[0006] In accordance with their aggregate nature, interactive television systems provide content in several different communication protocols that can preferably be understood by the client or viewer receiving the information from the network controller / radio service provider.

Typically the client is a decoder with a processor having limited handling power and communication bandwidth.

ES 2 559 638 T3

Translation of the various protocols goes beyond the limited capacity handling available in the typical digital set-top box processor.

Additionally, there are multiple sources that use a multitude of web authoring tools to create content.

These fonts tend to use Hypertext Markup Language (HTLM) as a standard with JavaScript embedded in HTLM pages.

JavaScript are typically interpreted.

Client devices typically have limited handling power and bandwidth, are unable to interpret, and have to execute interpretive language in a fast and efficient manner.

Thus, there is a need for a robust client and server architecture, which eliminates the need for interpretation of JavaScript embedded in the HTLM code so that HTLM encoded content can be displayed by the client or digital set-top box processor without require an inordinate amount of processing power or communication bandwidth.

[0007] WO 01/0301 discloses a system and method for various coupling client platforms and diverse information services without necessarily requiring separately configured modules to couple each client platform and information service combination.

[0008] EP-A-0778522 discloses a computer that compiles programs driven by a compilation party and includes completers that, when the digital signature of the originating party of an architectural neutral program has been verified, compiles the architecture-neutral program code from the architecture-neutral program into the architecture-specific program code in the architecture-specific language identified by the information collector in the architecture-neutral program, and attaches to the architecture-specific program code a digital signature of the compilation part to generate an architecture specific program.

[0009] US-A-5432937 discloses a method that enables single release of applications for multiple architectures and operating systems and to provide ease of use of applications in multiple architectural environments.

[0010] According to the present invention there is provided a method for compiling a script for execution on a client device in a distributed configuration comprising: receiving an HTLM page containing at least one script from a service provider on a server; extract the script from the HTLM page into a filter; compile the script into client compatible code to run on a client device; transmit the compiled script to the client device; and run the compiled script on the client device.

The present invention also provided a kit for a kit for compiling scripts for execution on a client device in a distributed configuration comprising: a server memory for receiving an HTLM page containing at least one script from a provider of service on a server; an extract component to extract the script from the HTLM page into a filter; a compiler component to compile the script into compatible client code for execution on a client device; a communication link for transmitting the compiled script to the client device; and a client device for executing the compiled script.

Summary of the invention

[0012] The present invention addresses the needs of the interactive television environment mentioned above.

The present invention provides a method and equipment comprising software and hardware for accepting and extracting an interpretive language, such as JavaScript from a contribution language, such as HTLM, and compiling the interpretive language for display on a client device.

A compiled JavaScript page common to a plurality of pages is sent only once and referenced as an external page by compiled pages, thus reducing the amount of data to be sent and associated bandwidth.

The viewer or customer can be a viewer to a (STB), a mobile phone user, digital assistants, a pocket PC or any other electronic receiving device.

[0013] The present invention provides a clear advantage over known systems.

The present invention makes it possible to extract scripts from an HTLM page and compile the scripts on a server, for execution on a client device, which is an improvement over known systems where a browser interprets and executes the scripts on the same machine.

The present invention also bundles scripts for each language, for example JavaScript or any other scripting language, of an HTLM document into a single package, for passing to the compiler, so that some or all of the scripts are compiled together.

Scripts enter HTLM documents in many ways.

For example, enter a pair of <SCRIPT> and </SCRIPT> tags, or as an attribute value for event handlers.

ES 2 559 638 T3

The present invention parses the HTLM document, adds the script (for a specific language, eg JavaScript) into a package, and then calls the compiler.

Some pieces of scripts (eg bundled scripts) can be compiled separately into different modules. All modules are sent to the client device for execution.

This allows, for example, compiled scripts to be shared across different HTLM pages.

This means that the compiler has a built-in compiling script interface that may be different from compiling the main document scripts.

Thus, it is easier and simpler to create a single compiled module.

[0014] The client device knows how to link and execute pieces of compiled scripts, as if it were a single script. Compiled scripts can be saved, so compiling does not occur if the script is already cached.

The present invention also provides a compilation temporary marker in scripts so that code is executed only in the usual HTLM browsers (ie never executed on the client device).

In previous systems they allow the script to test at execution time which browser is working (Internet Explorer, Netscape, etc).

In the present invention, the preferred compiler recognizes a key, eg, JS2O.

So in a piece of code like: if (JS20) DO_A; else DO_B; the compiler will not compile DO_B since it knows that if (JS20) is always true.

Thus, every piece of code is actually compiled as DO_A, the script compiler does not compile code that is never executed on the client device, thus reducing the size of compiled code, and improving code execution time.

The compiler replaces some late link references by compiling temporary links for faster execution on the client device.

Legacy systems resolve references at run time.

For example, in JavaScript, when a tag foo is accessed, the script engine will look for the name foo in a scope string.

This takes time of course.

Here the compiler binds (in some cases) the foo tag to a specific address for quick runtime access.

For example, in JS2O, (some) properties are allocated memory space as regular global variables in C language, and (some) other properties are allocated ranges on the stack as regular local variables in C.

The compiler replaces some late link references with absolute values ​​for faster execution on the client device.

In this embodiment, instead of binding to an address, the compiler replaces the label directly with a value.

For example, in JavaScript, the NaN tag is a property of an object.

Here the compiler directly replaces references to NaN with their value.

[0015] The preferred compiler carries an interface for defining new classes of objects.

This enables the compiler to access and / or optimize creation and manipulation of those objects, and allows the runtime to link to the code for this class.

The class code can be implemented as an open TV module.

In a preferred embodiment, H2O defines an HTLM syntax for declaring new classes of objects.

The compiler supports an interface to define predefined / external example of objects that enables the compiler to access and / or optimize manipulation of those objects, and allows the runtime to access those objects. Those objects are created outside of script execution.

In a preferred embodiment, H2O defines an HTLM syntax for declaring predefined / external example of objects.

Brief description of the drawings

Other objects and advantages of the invention will become apparent upon reading the following detailed description and with reference to the attached drawings where:

Figure 1 is an illustration of a header providing content to a client device;

Figure 2 is an illustration of a header providing content to a client device;

Figure 3 is an illustration of a header providing content to a client device;

Figure 4 is an illustration of a header providing content to a client device;

Figure 5 is a transcoder architecture diagram of HTLM H2O;

Figure 6 is a H2O browser processor and data flow diagram;

Figure 7 illustrates an interface between H2O and JS20;

Figures 8 illustrate the JS2O compiler components;

ES 2 559 638 T3

Figure 9 illustrates the compiler as a JS20 command line compiler;

Figure 10 illustrates execution of the JS compiled main code module on the client;

Figure 11 illustrates a preferred data segment; Y

Figure 12 illustrates a preferred stack segment.

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will be described in detail herein.

It should be understood, however, that the drawings and detailed description thereof are not intended to limit the invention to the particular form described, but to the contrary, the invention will cover all modifications, equivalents and alternatives that fall within the spirit and scope of the present invention as defined by the appended claims.

Detailed description of a preferred embodiment

Turning now to Figure 1, the service platform 50 comprises a group of applications roughly divided into three categories, content conversion 204, transaction / business control functions 206 and transport conversion 207.

The service platform enables services 200 to interact with a customer 212.

Services 200 communicate via communication link 202 to service platform 50.

The service platform 50 successively communicates with a customer 212.

The client 212 can be an STB, digital assistants, a mobile phone, or any other communication device capable of communicating with the service platform through communication link 230.

The content conversion 204 and transport conversion services 207 provide the transport and communication function, and the business function services provide the business control functions.

[0019] As shown in Figure 2, transaction / business control functions 206 are distributed between the service platform and the client 212.

For example, a client may perform some business functions (for example, implement ad campaign rules and ad / business filters to select viewed ads) and select content, which are more suitable for the client 212 (for example, select an ad or program that fits the user profile).

The functions of figure 2 are expanded in figure 3.

As shown in Figure 3, business functions 206 comprise four major functional components: director of service 238, director of viewer 240, director of transaction 242, and director of advertising (Ad) 244.

An example of a high-level operation flow follows for a preferred embodiment.

Referring now to Figure 3, a service 200 negotiates with a network controller to offer a service to subscribers via the headend controller service platform.

The network or headend controller uses the service director 238 to record the services and negotiated business rules 222 (eg, schedule, bandwidth requirements, service access to viewer information) associated with the service.

The service director 238 stores service data 216 (eg URL address, content).

Based on business rules 222 and service data 216, service director 238 communicates with broadcast communication function 234 to retrieve content from the content provider.

[0021] When content is retrieved from service 200, it can be processed by content conversion 204 and content filters 224 to convert the content into a form suitable for client device 212.

The broadcast function 234 converts the content into a form suitable for the broadcast network 234.

Client 212 receives the converted content per broadcast link 211.

Client 212 and service 200 interact via point-to-point link 210 and point-to-point function 232, which are part of transport conversion 207.

Service 200 may comprise shopping, audio / video, gaming, polling, advertising, messaging, or any other service.

[0022] Client 212 communicates via point-to-point communication link 232 to service platform 50 and service 200.

Load balancer 236 interacts with business functions 206 to determine the optimal weight share between the broadcast 234 communication link 211 and the point-to-point communication link 210 232.

Platform business agents 226 use business rules 222 to control the interaction and exchange of information between service 200 and client 212.

For example, the network controller may choose to prevent service 200 access to user information.

Service 200 preferably pays a fee based on business rules 222 and service data 216 to access user information.

ES 2 559 638 T3

[0023] Viewer manager 240 stores customer / user information in user data 220.

Platform business agents 226 control the flow of information from viewer to service 200.

Transaction manager 242 records transactional information changed between service 200 and customer 212.

Based on business rules 222 and user data 220, advertising manager 244 determines which advertisements and what type of advertisements will be presented to the customer via broadcast link 211 and point-to-point link 210.

[0024] Figure 4 illustrates another example of a preferred implementation of service platform 50.

Services 200 provide shopping, chat, and other services either on the Internet or on another network or communication channel accessible to the network controller.

Using the service platform, the network controller accesses those services.

Business functions 206, comprising service manager 238, interacts with carousel manager 254 to retrieve content from a service 200.

The carousel comprises a repeating stream of audio / video / interactive data broadcast to service platform clients 50.

Carousel Director 254, Transaction Director 242, and Service Director 238 control content insertion and deletion of the broadcast carousel.

Service content is retrieved, converted into a client-friendly format by H2O 248.

H2O 248 is a possible implementation of content conversion 204 and content filter 224.

H2O converts HTLM content to human-readable content or service / client platform.

The converted content is formatted on a data carousel and multiplexed by open transmission unit 256 for broadcast to client 212.

Client 212 interacts with the services and if necessary communicates with the service platform and the 200 services. Point-to-point communication goes through the service gateway 246.

Service Gateway 246 executes transport conversion to convert the STB protocol into a platform business agents 226 and H2O248 expect and understand.

Load balancer 236 interacts with business functions 206, carousel manager 254, and service gateway 246 to determine the optimal load between broadcast link 241 and point-to-point communication link 210.

Business functions 206 interact with platform business agents 226 to control access and exchange of information between services 200 and client 212.

[0025] In a preferred embodiment of the present invention, H2O is a client / server solution, which enables Internet content developers to build interactive TV applications and services for network controllers managing the service platform.

The service platform enables viewer access to the largest pool of Internet content and talent put into the vastly growing global market for interactive TV applications.

The H20 server process converts Internet content (HTLM pages, ECMA scripts, and HTLM page formatting) into service platform assets.

The client process H2O makes the assets and interacts with the client 212.

In a t-Commerce / E-Commerce context, H2O enables e-commerce stores to use existing web tools to create shopping services and to interface with the preferred service platform (controller), using standard web protocol.

[0026] H2O acts as a proxy to the service gateway and broadcast tools to convert web content.

H2O receives HTLM from both broadcast and online sources.

The present invention enables websites to use their current HTTP servers and application servers to generate interactive TV content.

In a preferred embodiment, H2O converts HTLM, JavaScript, and Internet graphics into client-compatible code, preferably Ocode, a C-based OpenTV code that runs on a virtual machine on the set-top box.

Any other known or developed protocol can also be added to the H2O functionality.

H2O enables the service platform to communicate with customer's STBs that are not full browser capable and to create original user interfaces.

H2O enables service platform connection on any trading engine that uses only HTLM.

H20 is responsible for converting web content such as HTLM pages, JPG drawings, wave audio files, etc. in customer-friendly resources that can be easily utilized with minimal throughput and customer bandwidth.

[0027] The server side of H20 is an HTTP proxy, H2OS.

ES 2 559 638 T3

For other purposes, that one can be packaged as a DLL or a batch tool.

The client side of H20, an STB OCOD application, is H2OC.

H2OC is built on top of other service platform client components, such as the service gateway library or the carousel load library.

H2O enables URLs to be used to reference documents and services.

H2O enables tracking in broadcast and online environments.

H2OS provides HTTP proxy functionality.

Service platform applications request a document through H2O.

H2O retrieves the document, parses it, compiles it, and returns the document to the requester.

This H2O functionality enables use of the same engine for different uses, online and broadcast, facilitates scalability, and enables flexible use of H20.

The analysis depends on the type of document, for example H2O analysis can be HTLM analysis, a GIF image, or JPEG images, etc. To make it expandable, H2O provides plug-in functionality and uses new third-party filters.

[0028] H2O carries special labels comprising: A / V control, channel control; control on the display screen (OSD); and Triggers.

W3C labels carried by H2O comprise: controlled position of graphic elements (x, y, z).

Javascript libraries comprise math, DOM, and date.

The H2O client side, H2OC, composes graphics assets on the client or STB.

H2O enables updated display of a user page view upon receipt.

H2OC uses libraries (communication, carousel, et al.) Provided by other service platform components.

H2O enables updating a page in a single update, but also provides an option to choose between partial updates as assets are loaded, rather than waiting for all or some assets to load. H2O enables dynamic connection / disconnection of third party classes.

[0029] In broadcast mode, preferably, a global permanent object is provided which is unclear when a new page is started.

The permanent object maintains context between pages.

Other base objects provided by the service platform are made permanent also in the transition (eg station control, OSD).

Apparatus are customer-defined methods.

Widgets are defined through an interface definition language to allow creation of new widgets, modification of widgets, and to allow adding methods without modification of the JS2O compiler 4000 of the present invention.

Now returning to Figures 5 and 6, a discussion of the main H2O components follows.

H2O transcoder 2001 converts HTLM contributions 2062 into H2O transcodes that can be efficiently and interactively viewed by an H2O browser on a client device, eg, an OpenTV STB.

H2O transcodes of H2O browser views into a limited Dynamic HTML4.

The host, such as HTTP proxy2003, invokes the H2O 2001 transcoder.

H2O 2001 transcoder interfaces with MIME 2036 driver and MIME 2028 information for content information in the non-HTLM MIME type.

The JS20 4000 compiler is multithreaded safe.

H2O transcoder invokes the H2O 2000 javaScript driver to catch scripts as contribution, catch external scripts or class URIs, and invokes JS2O compiler and pre-binding JavaScript.

The JS 2000 driver processes custom JS classes 2070 and shared JS scripts 2066.

[0031] Now going to figure 6, the browser H2O 2100 interfaces with JavaScript runtime JS20 2129 for JavaScript support.

The H2O transcoder works as a task, fetches MIME content through host HTTP proxy, and MIME content from processes as requested.

Preferably an interface has the proxy guest to control save mechanism for better efficiency. The H2O transcoder runs synchronously.

[0032] The H2O transcoder supports a selected subset of the standard HTML4.01 W3.

H2O transcoder supports a subset of text: paragraphs, lines, sentences; list subset; table subset and link subset.

The H2O transcoder supports a subset of object and picture elements.

ES 2 559 638 T3

The H2O transcoder also supports a filter authoring side object (for example, IE (Internet Explorer) custom object) and supports run-time custom objects for the STB; both the side of authorship (PC) and STB custom object class development; a subset of image map (client side, server side); a subset of shape and shape controls; script element; and a subset of JavaScript.

In the H2O transcoder, the HTLM nodes contain CSS information computed once at the element nodes.

Very little, if any, additional CSS is preserved.

This is fundamentally different from CSS dynamic cascade rules.

Dynamic styling is limited as a style change preferably applies to only one node.

This means that to search through the DOM for a property of the style of a particular element and expect it to return a valid value, the style property (for example style = color: red) is explicitly specific to the element within an inline style. , or explicitly created in JavaScript code so that PC emulation behaves similarly.

[0034] The present invention invokes a JavaScript handler task H2O to process data from the script element.

The JavaScript controller task takes the script URI, and invokes the JavaScript compiler JS20.

JS2O returns a data packet with compiled JavaScript code module.

JS20 can save compiled JavaScript scripts and finds similar repeated and identical JavaScript scripts.

[0035] The present invention generates H2O transcodes using client-compatible resources of internal data models of the parser program engine with limited layout and style information, and JavaScript codes.

A general H2O transcoding format specification comprises client compatible resource transcoding sections representing the document and JavaScript codes for the client or STB.

The transcoding format contains information about the document in the branch structure.

The format is efficient, compact, and expandable.

The format provides a version number to ensure compliance on the client or STB.

[0036] A client compatible object model, for example, in a preferred embodiment, the OTV Object Model (OOM) is provided for a programmer to create custom classes.

The OOM provides a mechanism to develop a custom object class, upload / register / unregister / download class, and access class interface codes to manipulate custom objects

The design and implementation of OOM uses the JavaScript object model to avoid duplication of effort.

The OOM provides an interface to allow JavaScript and C programs to manipulate objects.

HTLM, OOM, and C programs can also work without JavaScript.

The present invention provides lightweight client-side class registration with selected naming scheme.

The registry enables associating a class module with a name and query.

OOM loads a class module and registers the module.

There is only one interface for a class.

The interface contains only methods.

Each method is associated with a unique string name in this interface scope.

The OOM provides a mechanism to create an object sample of a class and a class reference commodity to provide.

OOM takes care of the class download.

OOM defines flow of control and data flow between the H2O HTLM and the JavaScript engine.

OOM instantiates browser objects for the JavaScript engine.

OOM exposes DOM object access to the JavaScript engine.

An object of a class is an object whose method properties are the methods of the class interface.

The OOM defines interfaces, guidelines, and a subset of the SDK API for custom objects to be integrated into the view structure, view update, event handling, focus, and access for shared system resources.

[0037] A controller directs component and browser behavior, and handles events.

The controller provides fast start-up time response, achieved by various techniques such as visual display during startup.

The preferred driver of the present invention uses system resources: event, download, mpeg, osd A / V, etc. and controls data model and view.

The controller also handles raw and processes client events (preferably OpenTV) 2146.

ES 2 559 638 T3

The controller handles primitive object events, which in turn raise a DOM 2140,2134 event.

The present invention claims to handle bubbling event DOM 2138 and uses focused node as a start node. DOM events can be handled by JavaScript 2128 event handler codes.

[0038] The preferred controller pre-defines element classes and is thus more efficient than custom classes.

The controller using URI retriever gets URI content, makes HTTP: gets and publishes (form post) requests, gets responses, and provides open and document back / forward functions.

In a preferred embodiment, data models are primarily HTLM DOM runtime, and other categories of runtime data models.

HTLM DOM also contains view information that reflects its intended effects.

[0039] Vista preferably supports different color styles, and treats the color table as a shared resource.

In a preferred embodiment, a limited set of MIME-like drivers are provided depending on the configuration to save memory.

Popular HTLM browsers for PC environments typically expose browser-specific guest objects for the JavaScript runtime to take care of.

The present invention supports a subset of Microsoft Internet Explorer 5 (IE5) guest objects for JavaScript runtime.

[0040] The present invention invokes the H2O JavaScript type controller (JS controller).

The JS handler traverses the element branch to collect global code, functions, binding references to external scripts, object class binding references, and JavaScript guest (event handler attributes) codes.

H2O invokes the H2O JavaScript handler and passes this collection to it.

The JavaScript controller task takes MIME class content and script, and invokes the JS20 JavaScript compiler which returns a client-friendly code module containing the compiled JavaScript codes.

Script pickup takes controllers back to codes.

The function is invoked as shown in the software appendix.

The transcoder traverses the node branch of the item and generates client-compliant transcodes, eg OTV H2O using the internal client-compliant resource generator. The present invention configures components, display, commissioning, etc. Static and dynamic settings are statically determined to compile time.

Turning now to Figures 7 and 8, the JS20 compiler 3904 interfaces 3902 with the H2O 3900 engine to compile JS code into a client compatible code module 3906, preferably an OpenTV ocode module.

The JS 4000 compiler interfaces with the H2O engine that uses a C / C ++ API as described below.

The JS20 compiler is reentrant and is divided into the following components: a JS20 4002 page element compiler, a JS2O 4004 cache, a JS20 4006 interface, and a 4008 backend JS2O ocode 4010 binary assembler and 4012 code module generator.

All compiler components are reentrant and use memory buffers to pass data from one to the other.

Turning now to Figure 8 and also referring to Figure 5, an H2O filter 2064 extracts incoming Javascripts from incoming HTLM pages 2062 and sends them to the page element compiler 4002 for aggregation within a single sample page.

H2O receives HTLM pages from both the broadcast link and the online connection.

Page element compiler 4002 receives JS elements from H2O 2030 (coming from an HTLM page), internally gathers all elements for an HTLM page into a single block of JS code, and then calls JS compiler 4000 to compile the JS page in a code module.

A JS page is the aggregation of all JS code from one or more HTLM pages.

The 3902,3906 interface between H2O and the JS20 page element compiler is described below.

[0044] The optional JS20 cache 4004 receives a JS page, and compares that page with other compiled cached pages.

If stored, the stored page is used.

If not already stored, JS20 calls the JS 4006 compiler.

Caching is preferably done for the last 100 pages compiled.

All JS20 compiler threads share the cache, so access to the cache is protected.

The JS 4006 compiler interface compiles the JS code first into an intermediary format, and then into a client-compatible code module that uses the 4012 specific code generator for JS20.

ES 2 559 638 T3

[0045] The back end JS Compiler 4008 receives the entire JS page as a pre-parsed and pre-compiled tree.

The JS compiler back end generates the client-compatible opcodes, for example ocode opcodes, directly in binary format using the output of the binary 4010 assembler.

The JS compiler back end generates a client-compliant code module in the 4012 code module generator.

The 4010 client-compliant binary assembler, for example, the Ocode (OTV-specific) binary assembler provides an API for generating client-compliant binary opcodes.

This assembler supports the opcodes needed by the JS compiler.

[0046] The present invention also creates, when an option is specified, a font assembly file. This file contains all the debug information (.stabs) and the exact same code / data as the binary compiler. This assembly file can be compiled separately for those who want to debug JS source code pages.

The 4012 code module generator provides an API to contribute the binary opcodes and outputs a 4102 client compliant code module.

Preferably, the present invention also generates a client compatible module header (in memory) to hold Meta information.

The JS20 compiler enables testing and acceptance of the JS compiler, and also enables testing of the client-friendly ocode generator and 4002 page element compiler.

Turning now to figure 9, in one mode of operation, the JS20 4100 command line compiler functions as a simple command line interface that takes a source JS file as a contribution and outputs a 4112 client compatible Ocode assembly file .

The JS20 compiler can also optionally contribute an external object class definition.

[0048] Command line interface 4104 communicates with JS2O page element compiler 4004 with the same API as H2O, ie (js2o_compile ... API as defined in JS20 FFS).

The following options are available for the JS20 command line compiler.

Js2o -g -O -i inputfile -o outputfile -c classmodule -p yam classmodule

-i: input file, -o: output file, -g: generate debug information, -O: optimize,

-c: defines external object class, classmodule is a client compatible code module with special header information, -p: defines a predefined object named yam (name) and of class defined by code module classmodule.

[0049] The output file is compiled with a client-friendly compiler, for example, an ocode assembler from the OpenTV Software Development Kit (SDK #) or with a C compiler interface (for example, gcco).

Ocode's binary assembler and code module generator work in the same binary object format. The SDK tools provide an 'a.out' format for Ocode object files.

[0050] The H2O 4202 runtime and JS2O 4204 runtime may be part of the same client-compatible code module.

In a preferred embodiment, the predefined class modules 4200 are the code for the DOM and built-in OOM object classes.

The JS2O runtime includes the JS built-in classes.

The JS2O 4000 compiler generates the main code module JS 4206 and the external code module JS 4208. External class module 4210 and other modules are preferably C modules.

[0051] JS2O provides a compatible client eg Ocode library that links to all compiled JS code modules.

This library is made up of small functions.

Large functions are stored in the JS20 runtime module.

For example an add two integers function is in the Ocode library, but a generic add function of any type is in the runtime JS module.

[0052] All values ​​pushed into the stack are preferably js2o type to accommodate trash collection.

It is possible in some cases to push in some non-js2o values ​​when it is certain that those values ​​emerge before any garbage collection can occur.

This happens when the compiler issues a set of atomic instructions, as shown in the software appendix.

ES 2 559 638 T3

Collecting filth

[0053] The garbage collector (GC) manages memory allocation for JS2O dynamic strings and objects.

The GC starts from scratch every time a new page is started (all previously allocated memory is preferably discarded).

The GC uses a mark and sweep algorithm.

Brand equity increases by one each time a new filth collection is started.

Thus, GC does not need a second step to empty the marks.

[0054] The JS20 runtime engine creates objects and strings dynamically.

Those are the ones that are collected as filth.

Dynamically created objects and strings are referenced through variables (local or global), through temporary values ​​on the stack, and through object properties.

The mark and sweep algorithm has to go through all of them to mark the used items.

[0055] Persistent page objects are those that are kept alive across multiple pages.

Lingering page objects preferably do not hold a reference to a JS value (object or string or other) to avoid problems when pages are changed when modules are unlinked.

Page lingering objects preferably make their own copy of data.

Turning now to figure 11 and figure 12, JS global variables used in a page and objects referenced in a page (objects still predefined) are assigned (at compile time) to a slot in data segment 4300 of the module JS code main code.

The local variables and parameters each have a slot on the execution stack.

The compiler also generates intermediate values ​​or temp values ​​on the stack.

The marking algorithm goes through all those intervals and marks all dynamic objects and strings, just as it recursively marks all objects and strings referenced in properties of any object.

[0057] The dump provides an API, eg void js2o_mark_val (js2o_valjsval, int markvalue);

void js2o_gc_mark (int * js2o_fp, int * js2o_sp, int * js2o_first_fp, int markvalue).

[0058] The js2o_mark_val function marks the js2o value with the specified value.

This function is careful to call the MarkProperties object vtable it function if the value is an object, and takes care to mark the prototype value, if there is one.

The js2o_gc_mark function goes through all JS globals and all JS call stacks and marks all temporary, local, argument, and global values, as shown in figure 12.

The GC also checks 'number of args' ranges, but it doesn't make a difference in GC as they are of type js2o_int.

[0059] The present invention provides is a generic API for memorizing dynamic properties in a single string.

The API includes the property name and property index in that string for quick access to both.

This code assumes a maximum number of 255 properties, and a maximum property name length of 127 bytes (not including the last zero character).

[0060] Each property name is stored within a unique string in the format, N-name / where N is a single byte, which holds the characteristic property number +1.

Yam (name) is the property name itself.

This format assumes that '/' and 'are illegal characters for names.

N contains an index from 1 to 255.

The characters 7 and can be substituted for any character not used in valid names and numbers.

[0061] The following function sets a property name to a specific value.

If the property does not exist, it is added.

void prop set (js20_prop * prop, char 'name, js2o_val val);

[0062] The following function obtains a property, specifying the name.

If the property does not exist, it returns JS2O NULL.

Js2o val prop get (Js2o_prop * prop, char 'name);

ES 2 559 638 T3

[0063] The following function removes a property, specifying the name.

If the property does not exist, nothing happens.

Void prop remove {js2o_prop * prop, char 'name);

[0064] The following function obtains the name of a property, specifying an index. (0 to n). The function returns JS2O NULL if this index does not exist.

This function assumes that it is called with a consecutive index number, starting with 0. js2o-val prop-indexgetname (js2o_prop * prop, int index).

[0065] The following function marks all properties with the specific mark value, used for garbage collection.

void prop mark (js2o_prop * prop, int markvalue);

[0066] The following function frees all memory used internally by this property list, void prop free (js2o_prop * prop).

[0067] The js2o runtime provides the following active principles: js2o_obj * js2o_funcobj_create (js2o_obj * this, void * func);

[0068] This function creates a function object with the specific cursor 'this' and function address.

Every time the function is called, the specific cursor 'this' is passed as the first parameter, void js2o_funcobj_delete (js2o_obj * objf);

[0069] This function deletes a function object.

It doesn't actually erase it.

The removal will be done by the garbage collection later if no one references this object.

The function restores the object to null values, so it is safe to access this object (optionally generates run-time or error warning, but will not shred from test to run non-existent code).

void js2o_to_null_object (js2o_obj * obj, size t size);

[0070] This function is used to change an existing object into an object of type JS2O NULL OBJECT.

The size ensures that the original object is large enough to be transformed into a null object.

This function can also be used to safely 'drop' an object, which can be referenced by some variables.

js2o_val js2o_dstr_create (char * str);

[0071] This function creates a JS2O chain type with the specific char chain.

The string is copied here.

js2b_val js2o_dstr_create_static (char * str);

[0072] This function creates a JS20 string type with the specified string car.

The string is not copied here.

The str pointer is assumed to be valid.

[0073] The JavaScript language in JS20 is a Language subset of ECMAScript Language ECMA-262. Some features not supported in JS20 are those that would require compilation on the client device.

Other support considerations included are runtime speed, including compiler optimization capabilities, runtime size, and usability in an STB / client device environment.

The following JS features are not supported in JS20 in the present example of a preferred embodiment.

[0074] RegExp class, Eval function, definition of nested functions, call object, argument object, with statement, function constructors with dynamic or body arguments, Watch / unwatch, parent and _proto_ methods (browser characteristics), ImplicitThis attribute , ImplicitParents attribute, Try / Catch / Throw statements and all error objects, other selected methods and properties of the predefined JS objects.

In a preferred embodiment, the following conditions are implemented in JS20, however, different parameters or limiting values ​​can be selected as desired.

Maximum property name length: 127 bytes (not including last null character); maximum number of properties for a single object: 255; integer values ​​are signed 29 bits (-268435456, # + 268435455); and float values ​​are 31 bits.

ES 2 559 638 T3

[0076] The return value of a constructors (if any) is discarded if the constructors do not return a different object.

Dynamic objects do not overshadow predefined objects.

The name of those predefined objects are reserved words.

Statically defined functions cannot be overshadowed by other functions (which means those methods are read-only properties of the global object).

A limited set of names is reserved.

All names beginning with JS20, with or without an underscore prefix are reserved.

Some functions will not be accessible as JS objects, for example, predefined global functions.

[0077] Runtime execution of a JS20 script has preferred behavior:

Exception handling: a runtime error can either do nothing, or stop JS execution, or even stop page rendering.

Compute Overflow: The runtime does not test for integer overflow.

[0078] The following JS objects are supported by JS2O.

Object; Math; Chain; Number; Boolean; Collection; and Function. (Object; Math; String; Number; Boolean; Array; and Function).

JS20 includes support for specific predefined client compatible objects such as OSD, channels, etc. The window object has event, document, and navigator properties that are objects themselves.

The window object has many methods (for example, back 0).

All properties and methods of the window object are directly accessible.

[0079] The H2O (HTLM for client compatible code, eg Ocode) of the engine converts multiple HTLM Pages to client compatible format, eg OpenTV format in parallel.

Having a reentrant JS compiler simplifies the interface and improves performance.

The compiler is reentrant, and to perform as many optimizations as possible, the compiler compiles all the JS code from a single HTLM page in one compilation.

[0080] To perform optimization for JS2O and other functions, the compiler provides the following features: the compiler gives specific error messages for unsupported features and.limitations, and parses the entire file before starting code generation (needed in particular for function called before its definition).

A compiler reference to a function preferably differentiates between functions defined in the current compilation, globally defined functions, and others.

[0081] Function objects: to differentiate how to access the object or a function call, reference to a variable differs in terms of local variables, global variables, and other variables.

The compiler enables determination as to whether a name refers to a known function, or a known variable.

A debug option is preferably used to turn debug messages on or off.

Optimization options are provided to turn various compiler optimizations on or off.

The compiler issues warnings if a function call is missing some arguments.

[0082] Variable types: in some cases, the compiler knows the type of a variable that is used.

The compiler maintains the type of variables in the code.

The type can also be 'Unknown'.

The compiler maintains Meta data (source file, line number, etc) so that the code generator can output debug information for program and data.

In particular, the compiler provides statically compiled access to the following: local variables, global variables (defined in the current compilation), functions (defined in the current compilation), and predefined objects and their properties.

The compiler provides an interface to import predefined object definitions.

Note that since there is no 'Block Scope' within a JS function (all local variables defined in a function are valid throughout the function, regardless of where they are declared), the compiler reserves space for all local variables within the function prologue .

By default all variables have the value JS2O_UNDEFINED.

The compiler prolog sets the value of all local variables.

All global variables 'uninitialized' (uninitialized) are set to that value.

[0083] The JS20 compiler provides an API with the H2O parser, as shown in the software appendix.

ES 2 559 638 T3

[0084] This API is multithreaded safe.

The order in which those APIs are called is obviously important to ensure orderly code generation.

[0085] The js2o_compile_create method creates a compilation controller; filename is the JavaScript source filename.

This filename is used only for error messages.

Compiled options are for the compiler (eg optimization, external file, debug, etc).

The function returns NULL if there is an error.

The js2o_compile_destroy method destroys the controller and frees all related memory.

The js2o_compile_generate method executes the actual compilation of all registered parts into a compiled chunk. After this only js2o_compile_error_msg or js2o_compile_destroy should be called.

The compiled data preferably comprises an OPENTV code module (in binary format).

The js2o_compile_error_msg method returns the last error message, suitable for an fprintf in the stderr.

The error message is released after a call to js2o_compile_destroy.

[0086] Method js2o_comp¡le_warning_callback registers a callback function for warning messages, 'callback' is a pointer to a callback function, and 'data' is a value, which will be passed to the callback function. call.

The prototype for the callback function is oid fuñe (void * data, char * msg, js2o_handle jh) '.

The warning message is destroyed after the callback call.

I register a null callback to remove a callback.

By default, there is no callback function.

[0087] The js2o_compile_add_src method adds a piece of text code to the compilation, linenum is the line number of the first line of this code, and we assume it is from the specified file injs2o_compile_create.

The control parameter is used for event handler code: in that case the control is a pointer used to return a control value.

This control value is preferably used at runtime to execute this code (see also js2o_execute).

In other cases, that is, not an event handler, the control is null.

This function maintains an internal copy of the code.

[0088] Optimization: For multiple event handlers using the same code, js2o generates an example of the handler code.

The code preferably has all new lines (\ n characters) from the original source file, so line numbers are meaningful.

[0089] The js2o_comp¡le_add_bin method includes a pre-compiled js2o file.

Any global instructions in the precompiled file are executed to this position at run time.

The name is used by JS20 to locate the external module at runtime.

If the same file is included in different positions on an HTLM page, this API is preferably called each time with the same name.

The module points to client compatible code, for example an OpenTV code module (including header).

[0090] The js2o_compile_add_obj method defines an available predefined object, objname is the name of the object.

The class is defined by client-compatible code, for example .otv module (including header) pointed to by classmodule.

The module is not referenced at runtime by JS20 (the object is created by H2O).

Note that this API does not define a new accessible JS source code class.

[0091] The js2o_compile_add_class method defines an available predefined class.

The class is defined by client-compatible code, for example, .otv module pointed to by classmodule.

The class name (to be used in the 'new' JS instruction) is also specific within the module (module header).

The class name is used at runtime by JS20 to get the function constructors for this class.

[0092] The js2o_compile_add_element method defines a new DOM element.

This will add a global variable with the specific name.

The function returns a variable control.

This control is used at run time by H2O to initialize the address of this object.

ES 2 559 638 T3

An external JavaScript source file can be included in the HTLM page.

H2O compiles this JS source file before compiling the HTLM page itself. What H2O finally passes in the js2o_compile_add_bin API (to compile the JS code inside the HTLM page) is the already compiled JS file.

To compile an external source file, the H2O engine calls js2o_compile_API with the following warning: a special option 'external ref (external reference) is used in js2o_compile_create.

The API does not include an external file (it does not call js2o_compile_add_bin).

[0093] The JS20 compiler preferably keeps a cache of previously compiled JS pages (in memory), eg the last 100 pages.

Caching is done within JS2O because some pages will have different HTLM but the same JS HTL script embedded within HTML.

Thus the present invention saves the compilation of such JS code within JS20.

Here a JS page is simply the aggregation of all the JS code of an HTLM page.

Note that the http proxy inside H2O also implements caching.

Caching a JS page enables use of a common JS among a plurality of sample pages. This reduces the amount of data required to be sent to the STB or client.

[0094] JS code is encapsulated within a client compatible code module, for example an OpenTV Code Module.

In the case of HTML + JS, the client-friendly code module, eg Open TV code module, is preferably embedded within the H2O resource (as a big char collection).

The code module format enables source code debugging.

The compiler outputs the debug information in an .odb file.

Note however that the debugger does not know the JS20 types.

Preferably support is provided in gdbo for JS20 types.

JavaScript code is used within an HTLM page in different ways: JavaScript code can be entered within an HTLM page using one or more pairs of <SCRIPT> </SCRIPT> tags.

The syntax is preferably: <SCRIPT LANGUAGE = JavaScript> any JavaScript statements ... </SCRIPT>

[0095] All inline code and event handlers on a page are compiled into a single supported main client, eg Open TV module.

H2O and JS20 hold the reference to an external JavaScript file.

In H2O, an external source JS file is compiled, stored and loaded separately to improve performance. This enables submission of a single piece of code, although this file is used on many pages.

It is allowed to include the same file in a single HTLM page.

J20 precompiles the external JS files before compiling the main JS code.

An external file is compiled into a compatible DLL client, eg Open TV module.

The corresponding HTLM Syntax is: <SCRIPT SRC = URI LANGUAGE = JavaScript> </SCRIPT>, where URI points to a JavaScript source file.

[0096] An external JavaScript source file can contain any valid JS instruction, however, name conflicts with other working JS modules are possible.

For example, multiple vary χ statements; they are problematic from a conflict point of view, but multiple x = value are not (they are not).

Global code connection: the file is compiled into a module.

The module exports a function that contains all the global code.

This function is called at run time, as if the external code were online.

[0097] Variable connection: the precompiled file preferably exports all the global variables used by your code, either external (for example, y = 5), or internal (for example, var x = 4).

The compiled main JS code reserves some slot in its global variables for all those exported variables.

The precompiled code also includes ranges for your exported global variables, but those ranges actually hold pointers to the actual variables in the main code.

The addresses are initialized at run time.

[0098] Module connection: at runtime, H2O loads the precompiled module, creates a JS20 context, and then initializes the precompiled module (see js2o_dll_init).

This initialization executes the update of variable addresses from the main JS code to the precompiled module.

The specific name in jjs2o_compile_add_bin is used to reference the module at runtime.

ES 2 559 638 T3

[0099] H2O and JS2O support reference to an external precompiled file.

The corresponding hTLM Syntax is:

<SCRIPT SRC = URI LANGUAGE-'Open TV> </SCRIPT>, where URI points to a compatible client, for example, OpenTV code module JS file.

[0100] This code module defines and supports specific JS2O requirements.

Connection is the same as for an external source JS file.

A JS code segment can be specific as the value of an HTLM attribute (eg, onClick) to be executed when a specific event occurs.

In ECMA terminology, this is a 'host code'.

The syntax is:

OnAttribute- 'any JavaScript statements

[0101] All inlined code and event handlers for a page are compiled into a single main client-compatible module, eg Open TV Module.

An event handler can return True, False, or other status values.

For connection, JS20, at compile time, js2o_compild_add_sr returns a handle to H2O for this event handler.

This control is used at run time to reference the event handler code.

JS code can access client-friendly objects, for example, predefined Open TV objects (including DOM objects).

There is no declaration needed on HTLM pages.

[0102] For connection, at runtime, H2O preferably passes a collection of predefined object addresses to JS.

The list and order of the predefined objects in that collection is predefined (known by both H2O and JS20).

H2O preferably also passes a collection of global functions.

Those global functions can implement methods for predefined objects (for example, setVisibility method).

[0103] The following syntax example can be used to declare a new object class to be used in JavaScript.

The JS code can use 'new' JS controller to create an example of this class, <OBJECT CLASSID = otv _module_uri DECLARE> </OBJECT>

[0104] In this example, the otv module uri points to an Open TV code module.

This code module preferably conforms to the definition of class object module JS.

The H2O layer preferably makes sure that this .otv module is loaded before starting any JS scripts from this page.

[0105] For connection, at runtime JS20 asks H2O for the address of this module, using the class name.

The class name is embedded in the Open TV code module (passed at compile time to JS2O).

See also js2o_compile_add_class.

A unique ID identifies a DOM element. for example, <anchor id = foo ...>, <

src = xxx.otv id = glop>.

[0106] DOM elements are accessed in JS code as a regular global variable using that ID name.

In both cases, the object is created by H2O, not JS20.

Connection: At compile time, H2O registers this element with JS20, which returns a control.

This control is used at runtime by H2O to tell JS2O the address of this object.

[0107] JS20 provides its own data types (int, bool, float, objects, etc), which are the standard C types.

The generic C type for a JavaScript value is 'js2o_val'.

Includes all other JS types: js2o_int: integer value, js2o_float: float value, js2o_bool: Boolean value, yjs2o_ptr: pointer to objects, strings, etc.

[0108] For fast and efficient execution, the present invention provides a single 32-bit word to represent all types of JS20 data on the stack.

The following are the 6 basic types for all JS20 variables.

Any JS20 value is preferably compatible with one of the 6 basic types.

All types passed by value fit into this single 32-bit data, for simplicity.

ES 2 559 638 T3

[0109] The preferred float format is: seeeeeeeefffΓΓΓΓΓΓΓΓΓΓΓΓΓΓΓΓΓΓΓ with: 1 -bit s is sign bit. 0 means positive, 1 means negative. 8-bit e is exponent field.

The exponent bias is 127.

The 23-bit f is fraction field.

This means that the preferred float uses a 22-bit fraction field, instead of 23.

Macros are defined in the software appendix.

[0110] All JS object classes share a common structure.

The object structure definitions start with the same fields, and all classes vtable start with the same primary functions.

For quick access to the JS2O active principles and methods, the compiler knows the structure of all devices or at least the principle of the structure.

Due to the preferred 'vcall' opcode, a virtual table pointer is the first field in that structure.

The vtable itself contains the address of all mandatory functions for each widget, possibly followed by addresses of functions specific to that class.

The JS20 runtime also needs a type pointer, and a 'rototype' in each widget structure.

A start definition for JS20 objects if provided in the software appendix.

The vtable points to a collection of mandatory functions for any JS20 object class.

Mandatory functions are provided in the software appendix.

[0111] Those active principles are only called by the JS compiler subcomponents in a C type context. Some parameters are C types (eg int index, char * name), some are JS20 types (eg 'this' ( this) and return values).

Note that the order of the parameters reflects the order used by the JS compiler.

[0112] The following vtable functions are provided:

The function js2o_val GetProperty (js2o_obj * this, char * name) returns the property value of the specific property. Returns JS2O UNDEFINED if the property exists, but has no defined value.

Returns JS2O NULL if the property does not exist.

This function does not look through the prototype pointer, this will be done automatically by the JS2O runtime, if necessary.

This function can assume that the 'prototype' property is handled directly by the JS2O compiler.

However, the ValueOf and ToString properties are controlled by this function.

See also API ValueOf and ToString below.

If the property corresponds to a method, the return value is a js2o type of function.

[0113] A widget class can decide to only hold some of the well-known property names, and only with a literal name.

In this case, the properties are accessed with the GetNumberProperty / SetNumberProperty APIs and the GetProperty API returns JS2OJJNDEFINED.

[0114] Yam (name) is preferably a property name.

If the object is a collection type, 'yam' can also be the index in the collection.

It is an index if the name represents a valid string number (for example, 1).

In the case of the object holding collection and the name is an index, this function returns the corresponding article number.

[0115] The empty SetProperty (js2o_obj * this, char 'name, js2o_val value) function sets the specific property with value.

If the property does not exist, the widget can either create it (with that value) or simply do nothing.

This function returns value of NO.

This function can assume that the 'prototype' property is handled directly by the JS20 compiler, however the ValueOf and ToString properties are handled by this function.

[0116] Yam is normally a property name.

If the object is a collection type, 'yam' can also be the index in the collection.

It is an index if the name represents a valid string number (for example, 1).

In case the object holds collection and the name is an index, this function should set the corresponding article number, and update its 'lengt' (length) property (if appropriate).

ES 2 559 638 T3

[0117] The empty function * GetMethod (js2o_obj * this, char * name) returns the function address of this method.

If this property does not exist, or does not contain a function, a runtime exception is raised (see js2o_runtime_error).

The method returns a js2o_val value.

The method is called with the following arguments: js2o_obj * this, js2o_int nbarg, js2o_val arg1, ... js2o_val argN: Yam is usually a property name.

If the object is of type collection, 'yam' can also be the index in the collection.

It is an index if the name represents a valid string number (for example, 1).

In case the object holds collection and the name is an index, this function returns the function address that corresponds to the item number.

[0118] The function js2o_val GetlndexPropertyName (js2o_obj * this, int index) returns the name of the property / method with that index (0 to N).

This function returns JS20_NULL if the property / method does not exist.

Otherwise it returns a JS2O value string.

This function is mainly used for the JavaScript statement 'for / in' (for / en).

This function assumes that it is called on a sequence of indices: 0, 1,2 ...

[0119] The js2o_val ValueOf (js2o_obj * this) function returns the value of an object.

The value of an object is object specific.

The return type can be a number, Boolean, string, function, or even object.

This API is a shortcut for GetProperty (this, ValueOf) then a call to that method.

[0120] The js2o_str ToString (js2o_obj * this) function returns the string representation of the object value.

This function is a shortcut for GetProperty (this, 'ToString') then a call to that method.

[0121] The empty function * GetCall (js2o_obj * this) returns the address of a function to be executed.

This is normally called for function objects only.

Calling it for other objects can be considered a runtime error.

See, js2o_runtime_error.

For a function, this API is a shortcut for Valueof () + get address of function.

[0122] The empty DeleteProperty (js2o_obj * this, char * name) function removes the specific property.

If the property does not exist or cannot be removed, nothing happens.

[0123] The empty MarkProperties (js2o_obj * this, int markvalue) function is used by the JS20 dumpster to mark all the js2o_val values ​​referenced by this widget (except for the 'prototype' field which is done automatically by the JS20 engine).

In most cases, the js2o_val values ​​are simply the ones stored in the widget properties.

The apparatus calls the js2o_mark_val function to mark each js2o_val.

Failure to do so may result in the js2o_val (still referenced by the widget) being freed.

[0124] The function js2o_val GetNumberProperty (js2o_obj * this, int propertyynumber) is the same as the GetProperty, except that a property number is specific rather than a property name.

This API is used for predefined objects with predefined properties.

The property number comes from a list of well-known names.

[0125] The empty function SetNumberProperty (js2o_obj * this, int property number, js2o_yal value) is the same as the SetProperty, except that a property number is specific rather than a property name.

This API is used for predefined objects with predefined properties.

The property number comes from a list of well-known names.

[0126] The empty function * GetNumberMethod (js2o_obj * this, int property number) returns the function address of this method.

If this property does not exist, or does not contain a function, a runtime exception is raised (see js2o_runtime_error).

[0127] The empty DeleteObject (js2o_obj * this) function frees all resources internally allocated by the object.

This is the opposite of the object_new function of the object class.

This function frees the object itself.

ES 2 559 638 T3

The dumpster calls this function when an object is discovered as being no longer used.

Widget methods are normally accessed through the GetMethod API.

The widget returns the function address.

[0128] Each method executes in a JS20 context.

Each method is implemented with the following restrictions: each contribution parameter is of type 'js2o_val', not regular C type.

A return value is required (it can be JS2O_NULL).

The return value also has to be a js2o type, and each method has at least the following first two parameters: object pointer 'this' and the number of parameters passed.

For example, a JS2O foo method with two parameters X and Y can be declared in C as: js2o_val foo (js2o_obj * this, js2o_int nbarg, js2o_val x, js2o_val y,

[0129] When defining an external object or an external object class, it is possible to declare some predefined properties and methods.

[0130] A predefined vtable method is defined by name and by an index.

The index is the function number in the class vtable.

Due to functions required at the beginning of any vtable, the first available index is 13.

The compiler will optimize, where possible, access to predefined methods.

When defining an object, for example, OSD, with a predefined function, for example, shows, the JS Code OSD.show (); will be optimized (but not x.show (); although x equals OSD.).

[0131] JS2O + H2O defines a list of well-known property names.

Each name is joined with a string number.

The compiler optimizes access to well-known properties by calling the GetNumberProperty and SetNumberProperty object APIs.

If a method is not defined as a 'predefined vtable method', this may still be one of the well known property names.

In this case the compiler optimizes the method of obtaining the address by calling the GetNumberMethod API.

When that method is accessed as a property, the compiler uses the GetNumberProperty and SetNumberProperty API.

[0132] Whether a method can also be defined as a 'predefined global method'.

The method is a global function, which implements the method.

This function verifies that the object class is correct for this method, and then executes the actual functionality.

An error is generated if the object belongs to the wrong class.

The list of 'predefined global methods' is well known shared by all H2O components.

The address of those methods is passed to runtime by H2O (unique collection of addresses).

[0133] There is a well-known list of property names.

This list is known to the compiler and to the objects.

This list includes most (if not all) of the property names (and method) of the predefined objects (including DOM objects).

This list is only used for methods and properties accessed by the compiler, but not for other strings.

[0134] To optimize access to CSS properties, a well-known property name can include the character

For example, style.color can be declared as a single property name.

JS2O runtime includes garbage collection for dynamically created objects and dynamically created strings.

A Mark &amp; ​​Sweep mechanism is implemented for collecting dirt.

This is less expensive in terms of run-time speed than Reference Counters.

[0135] Garbage Collection preferably also keeps track of modules (class definition, external code modules) referenced by strings and objects (eg vtable, functions, static string, etc).

Lingering objects will provide reset functions for general cleaning of xrefs during page turning (ie download modules).

[0136] H2O provides a memory director, for example for module caching.

JS20 and its garbage can work hand in hand with H2O.

JS20 allocates many small chunks (objects; strings), while H2O allocates a few larger chunks.

ES 2 559 638 T3

JS2O provides a free function for H2O to be executed while nothing happens (no user contribution).

This empty function calls the garbage collection.

[0137] Function names: access to functions defined in the same file is optimized in the direct call to the function address.

These particular means the function cannot be changed dynamically.

Local variables are compiled at direct intervals on the stack.

Global variables are compiled into direct variables in data section memory.

All predefined objects are part of the global JS scope.

Predefined objects are directly referenced, as are their predefined methods and properties.

The window object and all its properties / methods are directly part of the global scope.

For example, window.document property can be accessed simply by document.

[0138] The main JS code and all JS event handlers (for a page) are compiled into a single code module.

The H2O layer calls an initialization function of this module.

This initialization function returns a JS2O context pointer.

[0139] js2o_cx * js2o_cx_create (void 'module, int ** DOMObjectHandle, js2o_obj ** DOMObjects, js2o_obj ** PredefinedObjects, void ** GlobalMethods);

[0140] The parameters are a pointer to the main module and pointers to created DOM objects (controls and addresses), a pointer to a collection of predefined object addresses, and a pointer to a collection of predefined global functions.

DOM object controls are the controls returned by js2o_compile_add_element.

This function returns NULL on error.

[0141] The 'module' parameter preferably points to the same data as that returned by js2o_compile_generate.

JS20 does not make a copy of this data, so it preferably remains valid until the destroy function removes it.

Also note that this data is read-only (JS2O does not write to that data).

Note that at least the window object is defined.

[0142] The JS2O context is destroyed (when it is no longer needed) by calling js2o_cx_destroy: void js2o_cx_destroy (js2o_cx * context);

[0143] To execute the main JS code, the H2O layer calls the following js2o_main (js2o_cx * context);

[0144] This function returns 0 for no error, or a negative number for run-time error.

To execute an event handler, the H2O layer calls the following API to execute the handler: int js2o_execute (js2o_cx * context, js2o_obj * this, int handle);

[0145] The control value is provided by the js2o_compile_add_src API at compile time.

The js2o_execute function returns the following values: JS2O_TRUE if the controller returns real, JS2O_FALSE if the controller returns false, JS2O NULL if a runtime error occurs, any js2o_val if no error, and the controller does not return a value.

Note that the JS runtime is preferably non-reentrant.

In a preferred embodiment, the js2o_main and js2o_execute functions cannot be called while another JS controller is running.

[0146] An external JS file is compiled into an Open TV DLL code module.

The H2O layer calls an initialization function of this module.

This initialization function is contributed by the context of JS20.

Thus, the main JS Module code is first initialized as follows: int js2o_dll_init (js2o_cx * context, char 'name, void' module).

The name parameter is the one passed at compile time (js2o_comp¡le_add_bin).

After this call, the functions defined in that module are available to the JS context.

The external JS code module also has an API to execute the global JS statement from this file.

ES 2 559 638 T3

In a preferred embodiment, the external JS code module is an Open TV code module with JS20 specific information stored in an Open TV module header.

The object class module defines a new class of objects.

This module is declared on the HTLM page with the object declaration, and declared to the compiler using the js2o_compile_add_class API. The JS2O engine calls the following C API, provided by this module, to get the function constructors of this class of object.

[0147] Function js2o_obj * module_class_get_constructor (js2o_cx * context, char * classname): is exported function # 0. The object class module, in a preferred embodiment, is an Open TV code module with JS20 specific information stored in an Open TV module header.

[0148] JS runtime accesses the following function provided by the H2O runtime structure: js2o_obj * h2o_get_class_constructor (js2o_cx * context, char * classname).

This function preferably returns the function constructor object for the specific class

The class name is the same value as the one passed in the CLASSID of the OBJECT (object) declaration.

This function locates the class module internally and calls the module class get constructor function.

The following statement is available for JS to create an object of an outer class.

The name is the same as the specific one in the first passed in the ID class of the object declaration.

The following C active ingredients are available for library and object class development.

An empty function js2o_runtime_error (js2o_cx * context) executes when a runtime error occurs within a widget method or vtable function, and libraries within js2o, when an error condition occurs.

The char * js2o_get_number_property_string (int property Number) function returns the string associated with the well-known property number.

[0149] The present invention has been described in interactive television in a preferred embodiment, however, the present invention can also be embodied in a distributed configuration comprising a server and a client device.

In another embodiment, the present invention is implemented as a set of instructions on a computer readable medium, comprising ROM, RAM, CD ROM, Flash or any other computer readable medium, now known or unknown that when executed causes a computer to implement the method of the present invention.

[0150] While a preferred embodiment of the invention has been shown by the above invention, it is made by way of example only and is not intended to limit the scope of the invention, which is defined by the following claims.