DYNAMIC GENERATION OF OBJECT SCRIPT CODES
GENERATED APPLICATIONS RELATED APPLICATIONS
This application claims the benefit under 35 USC 119(e) of USSN 60/468,730 filed on May 6, 2003, USSN 60/436,914 filed on December 27, 2002 and a US provisional application with attorney docket number 291/03538 filed on May 30, 2003 titled "Generated
Applications". The disclosure of all of these applications is incorporated herein by reference.
FIELD OF THE INVENTION The present invention relates to creating dynamic script applications for browsers. BACKGROUND OF THE INVENTION In client server applications a server supplies data to clients responsive to client requests. In order to implement such an application a client needs an application specific or server specific interface. In some networks, for example Intranet networks or in the Internet, clients generally use a general purpose browser such as Microsoft Internet Explorer to interface many servers and many applications. When a client accesses a server and requests specific data, the server transmits to the client a program which is run by the general purpose browser. The program received from the server is in asta ndard format, i.e. a static HTML script document with optional dynamic functions (DHTML script), for example, using Java-Script to implement data entry capability. Applications performing complex functions, generally perform the functions at the server instead of delegating the work to the clients. The results of the functions performed at the server are used to create a new HTML document. A client station receives the new page and displays the results of the function.
Fig. 1 is a flow diagram 100 of executing a standard script application using a general purpose browser. Fig. 2 is a block diagram illustrating the execution of a standard script application 200.
In 102 a script 202ø is loaded into the general purpose browser. At 104 the browser executes script 202n. At 106 a user requests to perform a complex function or advance to further options of the application. At 108 the request is sent to the server. At 110 the server performs the complex function and creates script 202] or supplies the continuation of the application, script 202 . Act 102 is repeated loading script 202} and so forth until the last page of application 200, script 202n.
Using HTML with dynamic scripts (DHTML), in order to create complex applications tends to result in enormous scripts due to the weakness of the language.
Additionally, large scripts result in a slow initial download time to the average client. Further, such scripts may exceed the processing ability of the browser and maintaining such scripts is complicated due to their size.
One method used to delegate the process to the client and reduce the amount of data transmitted from the server to the client is by installing a dedicated program at the client as an addition to the browser or instead of the browser. However, such a solution is an annoyance to the user who needs to receive and install the application and select the correct application to interface with different servers. As a result clients may keep away from such applications. Additionally, upgrading requires obtaining a new copy of the program and reinstalling. Another method used to delegate the process to the client and reduce the amount of data transmitted from the server to the client is by providing fragments of compiled code (for example ActiveX), which perform complex processes or calculations instead of script code. The browser allows such code to execute external to the browser on the client station.
One of the problems with this solution is that the compiled code tends to be large thus slowing down the transmission of such scripts. A second problem is that allowing a client computer to receive and execute compiled code allows malicious programmers or hackers to gain access to a client's computer and cause damage. Therefore, browsers and firewalls include a commonly applied option of restricting such code from executing.
SUMMARY OF THE INVENTION An aspect of some embodiments of the present invention comprises a method of programming an application in script to be executed at a client browser, in which substantially an entire application is executed at the client browser. In some embodiments of the invention, the application controls its size by generating itself and erasing parts of itself during execution. In some embodiments of the invention, the application code is built up from objects which are dynamically generated as needed by generation scripts. Optionally the application code of an object and or its generation code are removed when not needed. In some embodiments of the invention, the generation scripts are downloaded from the server, as needed, in order to generate an object's code for the first time. In an exemplary embodiment of the invention, what is provided is software that generates itself on demand during or shortly after downloading and/or while it is being used.
An aspect of some embodiments of the invention, relates to a method of programming a client browser application in which substantially all or most of the scripts for generating objects are initially loaded as needed together and/or one at a time, in order to insert an object for it's first use. In some embodiments of the invention, more than 50, 70, 80 or 90 percent of
the objects and or the final runtime code for the objects comprising the application are generated by scripts, which are initially loaded as needed by the application for the objects first use. Optionally, all of the scripts for generating objects are initially loaded as needed by the application for the objects first use. In some embodiments of the invention, a single object generation script, may generate multiple object script codes. Optionally, the generated object script codes may be the same or may be different.
An aspect of some embodiments of the invention, relates to a method of programming a client browser application in which substantially all or most of the code for giving functionality to objects is generated by scripts when needed and optionally, erased when finishing their function. In some embodiments of the invention more than 50, 70, 80 or 90 percent of the objects and/or the final runtime code for them are represented by code that is generated by scripts when needed and optionally, erased when finishing their function.
Optionally, all of the displayable objects are represented by code that is generated by scripts when needed and optionally, erased when finishing their function.
An aspect of some embodiments of the invention, relates to a method of distributing real time data by a server in which the server buffers the received data and supplies it directly to the clients and to a filing system for historical retrieval.
An aspect of some embodiments of the invention relates to providing a windowing system capable of supporting an unspecified dynamic (e.g., substantially unlimited) number of windows (e.g., 4, 10, 20, 30 or any smaller, greater or intermediate number), on a browser. In an exemplary embodiment of the invention, each window displays a different HTML page or other data, for example the results of a JAVA program, ActiveX or directly communicated data. There is therefore provided in accordance to an exemplary embodiment of the invention, a method of creating a script application for execution by a general purpose browser at a client station comprising: loading a core script for execution at the client station, loading one or more object generation scripts based on instructions from the core script, dynamically generating one or more object script codes for execution by the client station browser, wherein the total memory size of the generated object script codes is larger than the core script; and terminating the script application by replacing the core script.
In an exemplary embodiment of the invention, said loading one or more object generation scripts comprises loading responsive to initialization of the core script.
Optionally, said loading one or more object generation scripts comprises loading responsive to commands in the core script.
In an exemplary embodiment of the invention, said loading one or more object generation scripts comprises loading responsive to the occurrence of an event defined by the core script.
Optionally, said dynamically generating one or more object script codes comprises generating responsive to the occurrence of an event defined by the core script.
In an exemplary embodiment of the invention, said dynamically generating one or more object script codes comprises generating responsive to code execution of the core script. Optionally, the method further comprises dynamically removing one or more of said generated object script codes during execution of said script application.
In an exemplary embodiment of the invention, said removing is responsive to the occurrence of an event.
Optionally, said removing is responsive to application workspace availability. In an exemplary embodiment of the invention, the removing is responsive to completion of the object script codes function.
Optionally, said removing of object codes of displayable objects is responsive to the removal of a represented image from a display.
In an exemplary embodiment of the invention, the method comprises generating at least 70% of the code of the script application with the object generation scripts.
Optionally, the method comprises generating at least 80% of the code of the script application with the object generation scripts.
In an exemplary embodiment of the invention, the method comprises generating at least 90% of the code of the script application with the object generation scripts. Optionally, the script application generates the display of a plurality windows.
In an exemplary embodiment of the invention, the position of said plurality of windows is controlled by said script application.
Optionally, the size of the plurality of windows is controlled by the script application.
In an exemplary embodiment of the invention, at least one of the plurality of windows displays dynamically changing data charts.
Optionally, at least one of the plurality of windows displays dynamically changing tables of data.
In an exemplary embodiment of the invention, at least one of the generated object script codes comprises method codes to vary the results of the object script codes.
Optionally, the method comprises generating distinct object script codes responsive to invoking a same object generation script with different parameters.
In an exemplary embodiment of the invention, the one or more object generation scripts comprise at least 5 object generation scripts. Optionally, the one or more object generation scripts comprise at least 10 object generation scripts.
In an exemplary embodiment of the invention, the one or more object script codes comprise at least ten distinct object script codes.
Optionally, at least one of the one or more object generation scripts generates multiple object script codes with distinct scripts.
In an exemplary embodiment of the invention, the size of the generated object script codes is at least 10 times the size of the core script.
Optionally, the size of the generated object script codes is at least 100 times the size of the core script. In an exemplary embodiment of the invention, the size of the generated object script codes is at least 1000 times the size of the core script.
Optionally, the method comprises hitially loading at least 50% of the object generation scripts prior to generating a first object script code.
In an exemplary embodiment of the invention, the method comprises initially loading at most 50% of the object generation scripts prior to generating a first object script code.
BRIEF DESCRIPTION OF THE DRAWINGS Non-limiting exemplary embodiments of the present invention will now be described in the following detailed description, with reference to the attached drawings, in which:
Fig. 1 is a flow diagram of executing a standard prior art script application using a general purpose browser;
Fig. 2 is a block diagram illustrating a standard prior art process of execution of a standard script application;
Fig. 3 is a flow diagram of executing a script application programmed according to an exemplary embodiment of the invention; Fig. 4 is a block diagram illustrating the execution of a script application, in accordance with an exemplary embodiment of the invention;
Fig. 5 is an illustration of a window system application as viewed from a general purpose client browser and programmed according to an exemplary embodiment of the invention;
Fig. 6 is an illustration of a drawing program using a drawing window as viewed from a general purpose client browser, according to an exemplary embodiment of the invention; and Fig. 7 is an illustration of the expansion of an application.
DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS GENERAL OVERVIEW
In an exemplary embodiment of the invention, an application server (for example a web server) provides a dynamic script application which executes entirely at a client browser, as described below. In some embodiments, this application may communicate with the server while executing. Optionally, a small program may be executed on the server to serve as a adjunct to the client script. However, unlike standard Java-Script implementations, in an exemplary embodiment of the invention, the client portion is not merely an interface for the server portion but an application on its own.
In an exemplary embodiment of the invention, various methods of controlling the client application size and/or providing the client application are provided and described below.
Fig. 3 is a flow diagram 300 of acts performed in executing a script application programmed according to an exemplary embodiment of the invention.
Fig. 4 is a block diagram of a dynamic script application 400 illustrating the execution of a script application in accordance with an exemplary embodiment of the present invention. In an exemplary embodiment of the invention, dynamic script application 400 is programmed by breaking down the functions that it needs to perform into basic building blocks 408 called objects for example as is commonly practiced in object oriented programming.
The application is optionally stored in an ungenerated form at the application server. The ungenerated form includes a core script 402 and object generation scripts 404. Core script 402 optionally comprises a standard HTML script which can be executed by the client browser. Core script 402, however, does not generally include HTML or script commands that affect the display of the application 400. Rather, core script 402 includes commands that control the generation of the commands of the application and may be viewed as a blue print or plan of the application to be generated. Object generation scripts 404 dynamically generate, on the client browser, the application object script codes 408 which form the dynamic script application. Optionally, the scripts are created by the generation scripts using template files (e.g., which are filled in and/or combined in various ways) and/or using script code (e.g., which is dedicated to prepare the script).
In contrast to prior art applications, in an exemplary embodiment of the invention, core script 402 lists generation scripts 404 that are used and/or the order they are to be used but does not include (e.g., in an initial download or in a same file) some or all of the generation scripts 404 in the core script 402, thus potentially greatly reducing the size of core script 402, required for performing the application. In an exemplary embodiment of the invention, the size of core script 402 is less than 10%, 1% or 0.1 % of the size of the resulting application.
In some embodiments of the invention, core script 402 may be transmitted to the client at a different time from the transmission of some or all of generation scripts 404. In addition, in some embodiments of the invention, one or more generation scripts 404 may be used by a plurality of different core scripts which describe different applications with common features. FLOW PROCESS
In an exemplary embodiment of the invention, when a client browser is instructed to access an application supplied by the server, the client transmits an application request to the server. Responsive to the client request, the server transmits core script 402 to the client browser, as indicated in 302. The client browser executes core script 402 which defines generation scripts 404, and performs initial commands to start the application, for example erasing the display.
In some embodiments of the invention, core script 402 includes one or more core segments which include commands for managing generation scripts 404. These commands may include commands to download generation scripts from the server and/or to run the generation scripts, causing their respective object script codes 408 to be generated. Alternatively or additionally, these commands may indicate when to erase an object script code 408.
In some embodiments of the invention, the one or more core segments are actuated responsive to the downloading of core script 402. Alternatively or additionally, one or more of the core segments are set to operate at a specific time, a specific time after the download, responsive to the performing of one or more other core segments and/or responsive to an external event (e.g. receiving a signal on a serial port). Alternatively or additionally, one or
„more of the core segments are actuated by events caused by a user action (e.g. pressing a key on a keyboard).
Possibly, some of object script codes 408 are event actuated and some are actuated by other object script codes 408 or by core script 402. Core script 402 defines the events that invoke each object (for example clicking the right mouse button).
The client browser comprises a work-area 406 known as the document object module (DOM), in which it places generated object script code 408. In some embodiments of the invention, core script 402 and/or object generator scripts 404 also reside in the client browser work area 406. Alternatively or additionally, the browser may assign different work areas for different types of scripts, for example one area for generated object script code 408 and one area for generation scripts 404. Optionally the code in object script code 408 may be further divided to an area for HTML code, and a separate area for Javascript or Nbscript.
Optionally, generation scripts 404 are stored in buffer 410 local to the client station in order to be locally accessible when needed to generate object script codes 408. h some embodiments of the invention, buffer 410 is in work-area 406 or comprises a memory internal to the browser program but not in work-area 406. Alternatively or additionally, buffer 410 comprises a memory local to the client station such as a hard disk so that a generation script, which is removed from the memory of the browser will be buffered at the client station in order to eliminate the need to retransmit generation scripts 404 from the server once they have been transmitted to the client station.
In an exemplary embodiment of the invention, generated object script code 408 comprises HTML code and optional script commands. The HTML code directly provides contents to the display, whereas the optional script commands for example Java script commands are invoked to perform changes on the generated HTML code. The script commands in object script code 408 are referred to in the art as methods. For example an HTML code that displays a line may be controlled by methods that allow changing the thickness or color of the line in response to user selections.
Changes to the HTML code in work area 406 are processed by the browser program and directly affects the display seen by the user. In contrast script code in work area 406 is invoked by control being transferred to the object, for example by the occurrence of an event
(for example receiving data on a communication line or an action taken by the user) or by control being transferred from a different script. hi some embodiments of the invention, object script codes 408 perform functions which directly affect the resulting display (for example an object that draws a circle). Alternatively or additionally, some of object script codes 408 do not directly affect the display (for example an object that receives data from the server).
In 304 core script 402 optionally, initializes an empty display and as mentioned above defines generation scripts 404 that are needed to perform the functions of the application.
In some embodiments of the invention, generation scripts 404 are loaded from the server after loading core script 402 and the application waits for them to load before starting. Alternatively or additionally, generation scripts 404 are loaded, as needed, by the application in order to reduce the initial application loading time, which directly affects the time a user waits for the application to start. In some embodiments of the invention, generation scripts 404, which are not loaded before the application starts are loaded in the background of the application, utilizing free processing power and free communication bandwidth.
In 306 as defined by core script 402 and performed by the client browser there are two paths of action which are optionally selected according to the action which core script 402 needs to perform:
The first path starting with act 308 comprises building the application by adding and/or updating object script code 408 in work-area 406 responsive to commands in core script 402 or events or user actions.
The second path starting with act 318 comprises removing unneeded script code by removing an object script code 408 from work-area 406 responsive to a command in core script 402 or as a result of an event (for example a user request to remove an object from the display).
In 308 an event is activated or the creation of an object is requested (for example core script 402 initiates the display of a window on the client station display). In 310 the browser checks if generation script 404 needed to create the requested object script code 408 to handle the user request has already been loaded to buffer 410. If generation script 404 is not in buffer 410 then in 312 generation script 404 is loaded from the server to buffer 410. In 314 generation scripts 404 are invoked to generate script codes 408 to display and manipulate the requested object, hi 316 the created code is placed in the browser work-area 406 in order for it to be processed 324 and or displayed to the user.
In 310, if generation script 404 is already in buffer 410, loading of the generation code 312 is skipped. It should be noted that some objects need to be placed multiple times in work- area 406, for example a displayable object must have HTML code to create every appearance of the object. Alternatively, some objects need to appear once in work-area 406 and can be accessed by multiple object script codes 408, for example a script routine that distributes buffered data from a server.
In 322 the browser checks if the object is still in work-area 406 from its previous use. If the object is not in work-area 406 the browser proceeds with 314 to generate the object as described above. Otherwise, in 326, object script code 408 can be copied to the new position
in work-area 406 where it is needed or it can be regenerated or a reference to an existing object script code 408 can be inserted in work-area 406 depending on the type of object as explained herein. In 324 the browser proceeds to process the script in work-area 406.
As mentioned above, a second path of action optionally initiated by core script 402 comprises in 318 the termination of handling an event, for example some events are performed by inserting object script code 408 to work-area 406 and the code is removed upon termination of handling the event. Additionally, 318 is performed when a user initiates the removal of an object which is no longer needed, for example closing a window in a window based application. In 320 the object script code 408 is removed from work-area 406. In some embodiments of the invention, checking if an object script code 408 is in work-area 406, indicated in act 322, is performed before checking if the corresponding object generation script 404 is loaded in buffer 410, indicated in act 310. An application that rarely removes object script code 408 from work area 406 would benefit from reversing the order since it would not need to check if generation script 404 is loaded if the object script code 408 is present in work-area 406.
OBJECT CODE GENERATION
In some embodiments of the invention, generation scripts 404 comprise script commands in accordance with a script language recognized by the client browser. Optionally, the script commands of generation scripts 404 are in accordance with a script language known in the art, for example Javascript or Nbscript. Alternatively or additionally, commands according to a generation script language widely recognized by client browsers, may be used. As described above, when a generation script 404 is executed by the client browser, the generation script 404 generates a respective object script code 408.
In some embodiments of the invention, the generated object script code 408 comprises HTML code and/or HTML code with methods as explained above, using internal generation commands of the script language recognized by the client browser. For example a single script command can be used to generate many different lines of HTML code to draw a triangle if there exists such a command in the script language. The type of triangle (e.g. isosceles, right), initial size and color, can be selected by the parameters of the command. Alternatively or additionally, if there does not exist a direct command to generate
HTML code for an object, it can be generated by connecting fragments of HTML code from multiple script commands or concatenating text.
Generally, the resulting object script code 408 is much larger in size than the generation script 404 which creates it, due to the result being comprised mainly of text
commands which lack the programming ability of the generation scripts. For example a hundred lines of text which follow a certain pattern or perform a known function can be expressed by a single script command or a small loop.
In some embodiments of the invention, a single generation script 404 may generate different script codes 408 representing different objects according to the event by which generation script 404 was invoked or the parameters used in invoking generation script 404 as defined in core script 402. For example one type of event may be defined to invoke generation script 404 with one set of parameters and a different generation script 404 may invoke generation script 404 with different parameters, resulting in different object script code 408. Optionally, some generation scripts 404 generate multiple object script codes 408 when invoked, for example in order to create an object and sub objects.
In some embodiments of the invention, generation script 404 may invoke other generation scripts 404, wherein each generation script generates one or more object script codes 408. In some embodiments of the invention, the application created by flow diagram 300 is performed entirely at the client station based on a single core script 402 received from an application server. Core script 402 is replaced only upon termination of the application. In contrast, prior art script applications as described in the background, do not build the application during its execution but instead receive the application from the application server that is in charge of generating the application.
In some embodiments of the invention, a single generation script 404, may generate more than 5 or 10 identical or distinct appearances of a script code 408 for a typical application. FIRST EXEMPLARY APPLICATION In an exemplary embodiment of the invention, an application comprising a window system interface is implemented using the method described above. The window system interface comprises windows and menus that can be opened and closed at the client station, without addressing the server to refresh the display. This type of interface is the standard interface for most common personal computer operating systems such as Microsoft windows 95/98. Despite the interface being so common, web applications do not incorporate such an interface, since a script application to support a window interface using the prior art script programming methods, would result in an unusable application. For.example, the application would be very large in order to include all necessary objects and alternatives. The application
loading time at an average client station would be very long causing users to avoid the application.
Fig. 5 is an illustration of a window system application as viewed from the browser and programmed according to an exemplary embodiment of the invention. In Fig. 5 a main window 500 comprises a movable menu bar 510 with optional buttons
512 to invoke sub application windows such as 520 and 530. Sub application windows 520 and 530 illustrate windows comprising representation of data. Windows 520 and 530 can be manipulated by a user (for example closing, moving and re-sizing the window).
In an exemplary embodiment of the invention, a window system application is created using the programming methods described above. In such a system a programmer defines the application as comprised of objects, wherein each object performs a specific function or leads to the display of a specific item. Optionally, objects utilize other objects in order to perform their function. LIST OF OBJECTS Following is a list of optional objects utilized in creating a window system according to an exemplary embodiment of the present invention. However, not all of these objects are required hi a usable windowing system, which generally requires a base window (e.g., at least the display, which may not be a real object) and child windows with controls and display areas. 1. Button - an object that displays a selectable button with text.
2. Alt - an object that displays a floating tag with a line of explanation text about the item under the mouse position.
3. ChartEngine - an object that creates graphs using graphic scripts.
4. Charts - an object to generate the content of a graph window (such as 520). 5. Combo - an object to display a roll down list of items from which to choose.
6. Glossary - an object that marks words in a text and retrieves explanations for the marked words.
7. GlossaryObj - an object to display the results of Glossary.
8. Manager - an object to load and remove objects from the work-area. 9. Menu - an object to handle the main menu (such as 510).
10. Menultem - an object to control a single item in Menu (such as 512).
11. MsgBox - an object to display a message to the user and return the users choice (such as: yes, no, ok).
12. OptionsObj - an object to hold a matrix of options for objects needing to choose between options.
13. RightMenuObj - an object to display a floating menu of options when a user clicks the right button of the mouse. 14. Settings - an object with details about the system and user.
15. TabStreep - an object that displays tabs of selectable sheets in a window (like in a 3 dimensional spreadsheet in Excel).
16. Tags - an object that inserts fixed text on button or other displayable objects.
17. WaitDiv - an object that displays a dynamic message while waiting for information to load for example from a database.
18. Window - an object for creating and manipulating a window.
19. Com - an object for receiving raw data from the server to use to create a graph or table.
20. Table - an object to create the contents of a table in a window such as 530.
The actual set of objects needed for a specific application depends on the functions performed by the application. Additionally, an application programmer talces into account that some functions are performed by objects and some functions are performed by methods generated with the object script code. For example a window object may display a window with initial characteristics defined by the generation script 404, and, have methods to resize the window, relocate the window and change the windows characteristics (such as type of frame and color). PERFORMANCE
A script application that is very large may suffer from poor performance at a typical client station. For example the application may run unbearably slow, it might freeze without warning or give unrelated error messages. Such a response at a typical client station to an application is caused by executing an application that is close to or exceeds the limitations of the browser. hi the prior art programming methods, a complex application which is built to execute as a single script from a client station, tends to be very large and may even have grown exponentially (as explained below) relative to a similar application created using the programming methods of the present invention. The reason for this difference is that the prior art application must include all options and variations in the original script inserted in work- area 406 since it does not build and condense the application as part of the application. In an application generated by the programming methods of the invention a programmer supplies one copy of an object, for example an object that places a button (a symbol that can be
clicked) on the display. The resulting application in work-area 406 may comprise multiple object script codes 408 with similar or identical code generated by a generation script 404. For example the resulting application performed in work-area 406 may comprise hundreds or thousands of appearances of the button object, although not all of the appearances need to reside simultaneously in work-area 406.
Fig. 7 is an illustration of the expansion of the size of an application.
In an exemplary embodiment of the invention, menu 510 from window system 500 is handled by generating to work-area 406 a menu object script code 702. Optionally, each item in the menu is handled by generating a menu item object script code 704 for each item in the menu. In an exemplary embodiment of the invention, each menu item needs 3 objects to handle the menu item:
1. a Button object 706 to handle selection of the menu item.
2. an Alt object 708 to display a floating text explaining what the button selects.
3. a Tag object 710 to insert an icon or text to the button. Due to the characteristics of HTML and the script code used by the browser, most of the code must be repeated in work-area 406 at least while being used by the application. Thus resulting in a tendency toward exponential growth of an application if it were to be ■ programmed according to prior art methods.
Large script-applications are much harder to maintain and they risk exceeding the limitations of the browser at the average client station, therefore many applications have not been created as dynamic script application which execute at the client station.
In some embodiments of the invention, the limitations above are overcome by inserting only the necessary objects script code 408 to perform the application at a specific time, and allowing removal of object script code 408 from work area 406 as needed by the application in order to prevent the application from growing so as to exceed the limitations of the browser. It should be noted that, in an exemplary embodiment of the invention, automatic generation on demand of script reduces the maintenance load on a programmer to the generation scripts and the templates used (if any). In some embodiments of the invention, traditional code may be used for some parts of the application, for example as part of the core script or as part of generated scripts. For example, HTML code may be used or downloadable objects may be used, for example JAVA and ActiveX.
In some embodiments of the invention, as mentioned above, as an application is executed, generation scripts are loaded from the server to buffer 410 when initially needed in order to generate the necessary object scripts. Thus spreading out the download of an
application so as to reduce the initial client wait. Generally, a generation script 404 that is loaded to buffer 410 resides on the client station until termination of the application. Optionally, a generation script 404 may be discarded if necessary and reloaded later if needed, if there is a shortage of storage space at the client station. In some embodiments of the invention, programming applications according to the methods of the invention reduce the load at the server by delegating the processing load from the server to the clients and optionally, reducing bandwidth consumption. In an exemplary embodiment of the invention, creating a graph at the client using raw data instead of creating it at the server and transferring a graphic file representing the graph to the client would reduce the computation load at the server and reduce transmission. MIXING PROGRAMMING METHODS
In an exemplary embodiment of the invention, the programming methods described above can be combined with prior art programming methods according to the requirements of the resulting application. In some embodiments of the invention, all of the executable object script code 408 is generated by generation scripts 404. Alternatively, most of the executable object script code 408 is generated by generation scripts 404, for example, more than 70%, 80% or 90%.
In some embodiments of the invention, some of the executable object script codes 408 are removed from work-area 406 during execution of the application. In some embodiments of the invention, all of generation scripts 404 are loaded after loading core script 402 and beginning to execute it. Alternatively, most of generation scripts 404 are loaded after loading core script 402 and beginning to execute it. In an exemplary embodiment of the invention, more than 70%), 80% or 90% of generation scripts 404 are loaded after loading core script 402 and beginning to execute it. DISPLAYING REALTIME DATA
In an exemplary embodiment of the invention, a window such as window 520 optionally, displays a graph of realtime data which is updated periodically. One method of supplying the data comprises a program running at the server which fetches realtime data from various sources. The data is buffered at the server and distributed to requesting clients and to a filling system to be stored in a database at the server for future retrieval as historical data. Optionally, the realtime data is delivered to clients directly from the server buffer and not from the filed database in order to cut down the overhead in delivering realtime data to requesting clients.
In some embodiments of the invention, an event controlled object script code 408 (for example invoked by a computer clock or by reception of data in a communication buffer) receives the realtime data sent from a server and buffers it at the client station. The realtime data is supplied to the client browser to locally update the graph displayed in a window as described above.
In an exemplary embodiment of the invention, the data shown is financial data from various sources. With each window optionally allowing local manipulation of the extent of data shown, its history (e.g. stored locally) and/or the method of presentation (e.g., graph, bar chart, numbers). This control is optionally provided by scripts generated for each window, as needed, for example as described above.
SECOND EXEMPLARY APPLICATION
In some embodiments of the invention, commonly used client applications which are installed on client workstations, for example Microsoft word and Excel, may be replaced by a server script application with a similar look and feel. Optionally, a user can connect using a standard generic browser to a server, supplying an application and utilize the application without installing the application locally.
Fig. 6 is an illustration of a drawing application 600 using a drawing window as viewed from a client browser, according to an exemplary embodiment of the invention.
In some embodiments of the invention, drawing window 600 comprises: 1. Pull-down menu's 610 to offer functional options for the application user.
2. Tools 620 from which a user can select to perform drawing function.
3. A color menu 630 from which a user can select colors to draw with.
4. A drawing area 640 on which a user draws.
5. An exit button 650 to terminate the application. In some embodiments of the invention, a server can supply and monitor usage of applications such as drawing application 600 without actually installing the application at the client station. By creating applications using the methods described above software suppliers can supply applications to clients and charge them for usage without actually installing the application at the client station. Optionally, an application can be protected by having the application require the user to be connected to the server in order for the application to function.
Optionally, a "save application" control is provided, so that a snapshot of the display, for example a drawing or a snapshot of the system, for example a windowing and data connection arrangement, can be used at a later date, even without the generation system. This
save may save all the objects or only the relevant ones, without generation code and bookkeeping code.
The present invention has been described using non-limiting detailed descriptions of embodiments thereof that are provided by way of example and are not intended to limit the scope of the invention. It should be understood that features and/or steps described with respect to one embodiment may be used with other embodiments and that not all embodiments of the invention have all of the features and/or steps shown in a particular figure or described with respect to one of the embodiments. Variations of embodiments described will occur to persons of the art. While the application has been described as methods, it is meant to also encompass apparatus for carrying out the invention, for example, suitably programmed servers and client computers and or media having suitable software thereon, for example, diskettes and computer RAM.
It is noted that some of the above described embodiments may describe the best mode contemplated by the inventors and therefore include structure, acts or details of structures and acts that may not be essential to the invention and which are described as examples. Structure and acts described herein are replaceable by equivalents which perform the same function, even if the structure or acts are different, as known in the art. Therefore, the scope of the invention is limited only by-the. elements and limitations as used in the claims. When used in the following claims, the terms "comprise", "include", "have" and their conjugates mean "including but not limited to".