METHOD AND SYSTEM FOR PROVIDING A SOURCE SOFTWARE DELIVERY SYSTEM
FIELD OF THE INVENTION
The present invention relates to a system for delivery software over a network.
BACKGROUND OF THE INVENTION The Holy Grail for software developers has been the ability to write one software program that can run on any hardware/software platform without having to be rewritten to accommodate the unique characteristics of the platform. For example, a program written in C, should run the same on the Windows 95/NT platform as it does on the Macintosh or UNIX platforms. Java, a programming language developed by Sun Microsystems, accomplishes this goal. Software written in Java can run on any platform that has a Java virtual machine. A virtual machine is an interpreter that translates Java bytecodes into processor instructions. Because of Java's portable architecture and compact design, it is used to create small applications, applets, which can be distributed over the internet. Although Java presents an elegant solution to a problem that has long plagued developers, the Java solution has several drawbacks.
1. Although Java has a compact design, a robust applet can still be sizeable.
Because the bandwidth of many networks (such as ISP-home modem) is limited, it can take a significant amount of time for an applet to download from the server to the client. 2. Since Java is an interpreted language, it is significantly slower than a compiled language. Users of Java applications can see a noticeable lag in the applications response time to user actions. Even with Just-in-Time compilation, Java programs will always be slower than compiled programs.
3. A large installed base of C, C++, Pascal programs already exist. To convert these programs to Java will take a significant amount of resources.
4. Java's algorithm specifications are controlled by Sun; the specifications may be written in a way that handicaps the performance of the program on other platforms.
5. Java programs can be decompiled, allowing others to easily see how
proprietary algorithms within the software work.
These problems have delayed Java's acceptance by the developer community.
Accordingly, what is needed is a system that overcomes the above-identified problems. The present invention addresses such a need.
SUMMARY OF THE INVENTION
A method and system for delivering software applications or applets over a distribution system such as the Internet in a fast and efficient manner is disclosed. The method and system includes converting a software program written in one language to a second program which is a very compact and portable language. The size of the second program is substantially smaller than the first program written in another language. This conversion provides a significant advantage over other distribution systems such as Java. In the present invention, the second program is downloaded from the server to the client computer. The client computer contains compilers, linkers, and object libraries needed to create the application from the second program's source file. Because the second program's source file is compact, the file's download time is minimal and file's compilation speed is faster than in conventional software delivery systems. The present invention has many advantages:
1. Since the second program's files are smaller than the original source code, they download quickly over the internet.
2. Since applications or applets are compiled, they run much faster than interpreted applications.
3. Any computer language can be used to create the source code for applications. 4. The compression algorithm associated with the present invention makes it difficult to reverse engineer to the original source code.
5. Since applications or applets are compiled, their execution speed is dependent solely on the speed of the computer system. The execution speed is not dependent on the performance of algorithms specified by an outside company. 6. The system makes it harder to determine how proprietary algorithms work in an original application.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 shows the path from the original source file to the application in source software delivery system.
Figure 2 is a flowchart of the Expressor algorithm. Figure 3 shows how SSDS uses DIFF files to upgrade applications on the client.
DETAILED DESCRIPTION
Definitions:
SSDS - Source Software Delivery System. SSDS is the system for delivering an application or applet from one place to another place. Usually the system being described is the internet where the goal of the system is to deliver an application or applet from the server computer to the client computer. An example of a delivery system is Java/HTML. Makefile-A text file which tells the linker which libraries should be linked in what order to the compiled source file(s). Archived file-An archived file is a file that acts as a container. The archive file holds the contents of many files. These hidden files can be extracted from the archived file in their entirety.
Ebo-A very compact language that describes a program's function. This description is done with the minimal number of characters needed to convey a program's function. Essentially, Ebo files lack the information necessary to make a program readable by people. Characters such as whitespace are eliminated. Function, procedure, and variable names; identifiers and other keywords contain only the number of characters needed to make the keyword unique to the compiler. Ebo files contain just enough information to be compiled into an application or applet that can perform the original program's function. Ebo files are created by Expressor
Expressor-A tool within SSDS which converts a software program written in one language to a program written in Ebo. Essentially Expressor compresses the source code to a minimal number of bytes needed to convey what the program does.
Comparator-A tool within SSDS which logs the differences between two Ebo files. The purpose of using the comparator is to create a Diff file that is sent over the network to update an older Ebo file. The Diff file is much smaller than the new Ebo file that makes
downloading faster.
Integrator-A tool on the Client side of SSDS which integrates the changes from the Diff file into the original Ebo file. The new resulting Ebo file is then compiled into the application.
Description of the Preferred Embodiment
The present invention relates to a system for delivering software over a network. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the preferred embodiment and the generic principles and features described herein will be readily apparent to those skilled in the art. Thus, the present invention is not intended to be limited to the embodiment shown but is to be accorded the widest scope consistent with the principles and features described herein.
Figure 1 is a block diagram showing the path from the original source file to the application using a system and method in accordance with the present invention. The original source file 102a contains source code for the application which may be written in a traditional language such as C, C++, or Java or the like. The conversion tool or Expressor 104 converts the original source code file written in one language to a second or Ebo file 106 written in the Ebo language by eliminating white space, replacing variable, procedure, and class names with a minimal set of characters. The Ebo language is a very compact language which describes a program's function. Essentially the Expressor 104 compresses the source code to a minimal number of bytes needed to convey what the program does. The log file 108 keeps a table of variable, procedure, and class names and the set of characters replacing them. Expressor 104 incorporates the makefile 102b into the converted source file resulting in Ebo file 106. The makefile 102b contains a description of how the Ebo Linker 120 on the client 110 should link the Ebo Libraries 122 with the compiled Ebo File. The Ebo file 106 is a compact file describing the application. The Ebo file 106 may be a single file or it may be an archived file containing the converted description of many source files.. The description in Ebo file 106 is created with the minimal characters needed. Essentially, Ebo files lack the information needed to make a program readable by people. Characters such as white space are eliminated. The Ebo file
106 is the file which is sent over the network to the client 110. Ebo files contain a representation of the makefile which tells the linker on the client system how to link the Ebo file(s) with the libraries residing on the client system.
Figure 1 shows a block diagram of the Client system 110. When the Ebo file 106 is downloaded on to the client system 106, it is checked to see if it is encrypted and compressed. If the Ebo file 106 is encrypted, it goes through the decryption 116a. If the Ebo file 106 is compressed, it goes through decompression 116b. The resulting Ebo file goes to the Ebo compiler 118. The result of the Ebo compiler 118 is an Ebo object code that goes to the Ebo linker 120. Using the makefile contained in the Ebo file 106, the Ebo linker 120 combines the Ebo object code with the correct Ebo libraries 122. The result is an application 124 if the Ebo file 106 represents an application; or an applet 124, if the Ebo file represents an applet embedded in a web page or email 114. -An application 124 will run on independent of any other application. -An applet 124 will require the client's browser to be connected to web page 114 to run. Figure 2 is a block diagram showing the processes involved in the conversion tool
104. First, the original source code file 202 is read, examined for reserved language keywords and the symbols which will replace those keywords, via step 204. Next, all unnecessary white space (tabs, spaces, carriage returns) is removed, via step 206. Then, all comment statements are removed, via step 208. The scope of variables and procedures is recorded via step 210a, and also whether each word is a procedure or variable is recorded, via step 210b. The number of bytes each variable and procedure name occupy within the source file 202 is counted, via step 212. Then the variables and procedure names are sorted into a list in order of the number of bytes each word occupies in the source file 202, via step 214. Each variable and procedure name in the source file 202 is replaced by a minimal number of characters, starting with a base character, in accordance with the number of bytes each word occupies in the file, via step 216. The word's scope and type is also taken into account in step 216. Each language keyword is replaced with a replacement symbol, via step 218. A second compact file 106 and 220, and a log file 108, is then created via step 220. If desired, this second compact file 106/220 may be compressed, via step 222, in which case a compressed second compact file 224 results. If desired, this second compact file 106/220 or the compressed second compact file 224 may be encrypted, via step 226, in
which case an encrypted second compact file or an encrypted, compressed second compact file 228 results.
Figure 3 is a block diagram which illustrates how the converter method and system in accordance with the present invention may be used in conjunction with a comparator and Diff File to compare and update differing versions of the second compact file produced by the converter method and system/algorithm.
Referring now to Figure 3, the previously released original source file 302 is sent to the converter method and system 304, producing a second compact file 306. The most recent version of the source file 308 is sent to the converter method and system 310, producing a second compact file 312. The first compact file 306 and second compact file
312 are then compared by the comparator tool 330. The comparator tool 330 logs the differences between two compact files by doing a byte by byte comparison of the different versions of the compact files, and then creates a Diff file 314 which is then sent over the network to update an older compact file 316. The Diff file 314 contains a log of only the changes between the two files 306 and 312. Because the Diff file 314 contains only a log, it is smaller than the original compact files 306 and 312, which makes it ideal for upgrading software.
The integrator 318 integrates the changes from the Diff file 314 into the previous version of the compact file 316. The result of the integrator 318 goes to the Ebo compiler 320. The result of the Ebo compiler 320 is an Ebo object code that goes to the Ebo linker
322. Using the makefile obtained from the integrator 318, the Ebo linker 322 combines the Ebo object code with the correct Ebo libraries 324. The result is an application 326 if the Ebo file 316 represents an application; or an applet 326, if the Ebo file represents an applet embedded in a web page or email. Although the present invention has been described in accordance with the embodiments shown, one of ordinary skill in the art will readily recognize that there could be variations to the embodiments and those variations would be within the spirit and scope of the present invention. Accordingly, many modifications may be made by one or ordinary skill in the art without departing from the spirit and scope of the appended claims.