 |
Description  |
|
|
BACKGROUND OF THE INVENTION
Microcomputers have evolved from simple 8-bit electronic toys to powerful
business management tools. Almost all large and medium size companies in
this country now use at least one microcomputer for business purposes. As
a result of mass production, the price of microcomputers dropped
drastically over the last few years. Currently, microcomputers are within
the reach of many homes and small companies.
In order to make computers more useful in a corporate environment, many
companies connect their desktop microcomputers in local area networks.
Currently, some companies also install wide-area communication networks so
that information can be shared among microcomputers dispersed over many
cities. The experiences of these companies confirm that sharing of
information among computers increases the overall productivity of the
whole system.
However, computers owned by different companies are generally not linked
together. Further, the computers owned by homes and small companies tend
to be stand-alone desktop machines. Consequently, there is no sharing of
information among all the computers. The availability of a wide-area
network called the "Internet" changes the situation and potentially allows
all these computer to be electronically connected.
The Internet grew out of research in the 1960s to design a robust wide-area
data communication network. For a long time, the Internet was used by
researchers in universities and national laboratories to share
information. As the existence of the Internet became more widely known,
many users outside of the academic/research community (e.g., employees of
large corporations) started to use Internet to carry electronic mails. In
late 1980s, a wide-area information system know as the World Wide Web
("the Web") was developed. The Web is a wide-area hypermedia information
publishing and retrieval system aimed to give universal access to a large
universe of documents. At that time, the Web was known to and used by the
academic/research community only. There was no easily available tool which
allows a technically untrained person to access the Web. An development in
Internet is the release of a software called a Web "browser." It has a
simple but powerful graphic interface. The browser allows a user to
retrieve web documents and navigate the Web using simple commands and
popular tools such as point-and-click. Because the user does not have to
be technically trained and the browser is pleasant to use, it has the
potential of opening up the Internet to the masses.
A document designed to be accessed and read over the Web is written in a
language called the "Hypertext Markup Language" (the "HTML"). The HTML
document, when interpreted by a Web browser, is able to display text,
images and other multimedia contents. However, the HTML document itself is
merely an ASCII coded text document together with "tags" of predefined
format that add some features to the basic text. As a result, the
multimedia presentation (e.g., computer display) generated by the HTML
document can only contain simple structure.
Another problem of HTML document is that it is difficult to design. As
explained above, HTML document is an ASCII coded document while the final
display is a multimedia presentation. It is not easy to relate the ASCII
document to the presentation. Even though there are tools that help users
to write HTML documents, these tools are not easy to use. Consequently,
only well-trained persons are able to design HTML documents. Thus, most
user can only be a recipient of information instead of being able to share
their information.
Recently, there are movements to improve the basic Web architecture. When
the Web was first developed, the aim was to share documents. It has been
pointed out that programs can also be shared over the Internet. In this
systems, a first computer can send program code to a second computer via
the Internet. The second computer then executes the code so as to
dynamically alter the display generated by a browser. As a result, the Web
can be changed from a passive wide-area document sharing system to a
dynamic information processing system. Examples of such developments are
Java and ActiveX. Java is a variation of a popular programming language
called "C++" while ActiveX derives from Microsoft's Object Linking and
Embedding (OLE).
Even though sharing program code is a powerful idea, the current direction
of implementation (e.g., Java and ActiveX) is counter to the trend of
opening the resource of the Internet to a large number of users. Both Java
and ActiveX require writing computer programs by experienced programmers.
These programs are more difficult to write than HTML documents. Thus, the
current direction reduces the number of users who can participate
interactively in the Internet experience.
SUMMARY OF THE INVENTION
The present invention involves applying a new programming architecture,
called the "digital cell technology," to a digital data network. In this
invention, the multimedia files used in the cells, which are program
modules used in developing applications and having a specialized
structure, could be obtained from other computers connected to the data
network. As a result, the number of multimedia files that could be used in
applications increases drastically.
Each cell in the digital cell technology is associated with one or more
parameter files (called DNA files). These files contain parameters to
define many characteristics of their associated cells. In some embodiment
of cells, the DNA files also provide means for cells to communicate with
each other. One aspect of the present invention involves distributing
these DNA files to various computers connected to a data network.
These and other features and advantages can be understood from the
following detailed description of the invention together with the
accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a drawing of a computer network which can be used in the present
invention.
FIG. 2 is a drawing showing multiple windows associated with program cells
of the present invention.
FIG. 3 is a drawing showing the structure of a DNA files of the present
invention.
FIG. 4 is a block diagram showing a cache design of the present invention.
FIG. 5 is a schematic diagram showing distributable DNA files of the
present invention.
FIG. 6 is a diagram showing a prior art programming architecture.
FIGS. 7A and 7B show a comparison between prior art architecture and the
architecture of the present invention.
FIG. 8 is a diagram showing the interaction of cells in accordance with the
present invention.
FIG. 9 shows a block diagram of the structure of a DNA file in accordance
with the present invention.
FIG. 10 shows a block diagram of the structure of a cell in accordance with
the present invention.
FIG. 11 is a block diagram of a computer system running an applications in
accordance with the present invention.
FIG. 12 shows various windows associated with visual cells during the
execution of a multimedia development system in accordance with the
present invention.
FIG. 13 shows a windows for a user to enter information to a DNA file of
the present invention.
FIG. 14 shows various windows associated with a button cell and visual
cells during the execution of a multimedia development system in
accordance with the present invention.
FIG. 15 is a window showing the format for a user to specify a button in
accordance with the present invention.
FIG. 16 is a window showing the format for a user to specie a visual cell
associated with a button cell in accordance with the present invention.
FIG. 17 is a flow chart showing a cell notification procedure in accordance
with the present invention.
DETAILED DESCRIPTION OF THE INVENTION
The present invention can be used in a computer network system 700 of FIG.
1. System 700 comprises a data communication network 702 (such as a local
area network, wide-are network, or the Internet) a plurality of servers,
such as servers 704-706, and a plurality of client computers, such as
computers 710-712. Preferably, the servers contain a large database of
multimedia content (such as images, audio files, video files, text
documents, etc.). The servers may also contain pointers to other computers
which contain such databases. Some of the client computers run an
operating environment designed under the "digital cell technology"
("DCT"). A detailed description of this technology is provided in a
section entitled "Detailed description of the DCT". This technology will
be described briefly here to the extent necessary to understand the
present invention. One aspect of the present invention is to extend DCT to
a data network environment.
Multimedia Files Downloaded from Remote Servers
In DCT, applications are formed by managing a plurality of small program
"cells." Each cell is associated with a parameter file (called "DNA" file
in the terminology of DCT). The DNA file contains parameters to define
some of the characteristics of its associated cell. The DNA file may also
provides means for one cell to communicate instructions with other cells.
In one implementation of DCT, some of the cells generate a display window
upon execution. FIG. 2 is a drawing showing a display 750 of a computer
monitor. It contains four display windows, 752, 764, 768 and 774, each
associated with a cell. The details of these windows will be explained
below.
FIG. 3 shows the structure of an exemplary DNA file 720 associated with a
cell CA. Cell CA resides in a client computer, such as computer 710. The
focus here is a statement 736 (i.e., "IMAGE=http://www.site/file.JPG")
under a "own parameter" section 722. In the cells disclosed in the section
entitled "Detailed Description of the DCT", the image file of its display
is located in the hard disk of the client computer. In the present
invention, the image file could be located in another computer connected
to network 702.
More specifically, each file accessible by computers connected to the Web
must have an address in a recognized format, called the Uniform Resource
Locator ("URL"), that enables computers all over the world to access it.
Statement 736 indicates that the image file has a URL of
"www.site/file.JPG". In order to obtain the image file, cell CA causes
client computer 710 to send a request (via network 702) for a file named
"file.JPG" to the server containing the file (such as server 704). In the
Microsoft ("MS") Windows environment, cell CA would call a WinSock module
to initiate a TCP/IP communication with server 704. In response, server
704 delivers the file "file.JPG" in its database to client computer 710,
which in turn delivers the file to cell CA using regular MS Windows
notification protocol. If server 704 is running under a MS Windows
environment, server 704 also uses a WinSock module to receive information
from and send information to client computer 710. As a result, cell CA can
generate a display window in accordance with the parameters in its
associated DNA file.
It should be noted that the downloaded file is not limited to image files.
Other types of files, such as audio and video files, can also be specified
in the own parameter section of a DNA file as remotely located files.
Further, the communication protocol does not have to be the hypertext
transport protocol (HTTP). Any kind of protocol allowing transfer of files
over network 702 could be used. Further, server 704 could operate under
various operating environments, including UNIX, Macintosh, and DCT.
Once the image file is obtained from the server, cell CA behaves like a
regular cell disclosed in the section entitled "Detailed Description of
the DCT". For example, a user can manipulate the cell by linking other
cells to it. Some of these linked cells may also obtain its image file
from various servers in the Internet. When these cells are launched, they
obtain their image (or other) files using the same method described above.
An example of this linking can be seen in FIG. 2. For illustrative
purposes, assume that window 752 is a display generated by cell CA of FIG.
3. It has a title bar 754 containing a title (i.e., "site 1") of the
display. In this illustrative example, the titles of all the windows in
FIG. 2 show the origin (i.e., in the form of server "site 1", "site 2",
etc.) of the display images. The actual title of a cell can, of course,
contain any words or symbols. Thus, windows 752, 764, 768 and 774 contain
images that are downloaded from sites 1, 2, 3 and 2, respectively. Window
752 also contains a tool bar 756 having a plurality of tools (such as tool
758) for manipulating window 752 (and the underlying cell). Examples of
tools are edit tool for accessing an edit mode (for editing the window)
and tools for invoking other pre-defined cells. In this embodiment of the
present invention, all the windows in display 750 have title bars and tool
bars
In this illustrative example, the image of window 752 includes a shape 761.
Users can link a button cell (represented as button 760) and a visual cell
(represented as symbol 762) to window 752. The method to link cells to an
existing cell has been disclosed in the section entitled "Detailed
Description of the DCT". Each of these two cells has a DNA file. The IMAGE
parameters in these DNA files could specify a local or a remote image
file. It should be noted that any number of (or none) cells can be linked
to window 752.
When a user clicks on button 760, the underlying button cell is launched.
Window 764 is generated. In this example, the image (having a shape 766)
is generated based on one of the files (called "file 1" in this example)
stored in site 2.
When a user click on symbol 760, the underlying visual cell is launched.
Window 768 is generated. In this example, the image (having a shape 770)
is generated based on a file in site 3. Users can attached another visual
cell (represented by a symbol 772) to window 768.
When a user click on symbol 772, the underlying visual cell is launched.
Window 774 is generated. In this example, the image (having a shape 776)
is generated based on another file (called "file 2" in this example)
stored in site 2.
Note that some of the cells in the illustrative example of FIG. 2 could
have a locally stored image file. There is no need to have all the image
files downloaded via network 702.
Windows 752, 756, 768 and 774 are each associated with a DNA file. The link
parameter sections of these DNA files contain the file names (both local
or remote) of the DNA files which are linked to the corresponding cells.
For example, the link parameter section of the DNA file associated with
window 752 contains the file names of the button and visual cells
associated with windows 764 and 768, respectively. In this example, the
file names are in URL format because these files are remotely located.
In the preferred embodiment of the present invention, a URL cache is
included. This cache stores in a hard disk all the URLs processed by a
client computer. FIG. 4 shows a block diagram showing an implementation of
the URL cache. When an exemplary cell 802 wishes to access a remote file,
it issues a command to a program module called the "internet resource
loader" 804. Loader 804 first check a cache list 806, which contains a
list of URLs that have previously been downloaded from the network and
stored in the local hard disk. Thus, each URL in the list is associated
with a file address in a local hard disk. When the URL of the desired file
is in cache list 806, loader 804 fetches the file from the local hard disk
instead of downloading it from the network. If the URL of the desired file
is not in cache list 806, loader 804 called WinSock 808 to download the
desired file. Upon receiving the remote file from the network, WinSock 808
delivers it to loader 804, which in turn causes the operating system to
store it in an appropriate local file. The address of the local file
together with the URL are added to cache list 806. From this time on, the
client computer has access to this file without the need to obtain it from
the network.
The implementation of loader 804 can be easily performed by a person
skilled in the art based on the above description of its activities.
It is know that some servers update the content of its files frequently.
For example, if a server contains files related to prices and
specification of products, these files need to be updated whenever the
price or specification information is changed. In the above embodiment,
the URL cache would prevent users from accessing these updated files
because loader 804 would fetch the files from its cache instead of from
the server. There are at least three methods to handle this situation. The
first method is to allow a user to clear all entries in the cache. As a
result, a remotely located file must be fetched from the network. The
second method is to allow a user to clear entries related to selected
applications. Thus, remotely located files related to these applications
will be fetched from the network. The third method is to allow a user to
remotely reload all files appearing on a screen. These methods can be
implemented using a number of ways. For example, the cache list could be
in ASCII form, and the entries therein could be erased (in total or
selectively), marked, or replaced in accordance with the desire of the
user.
Distributable DNA Files
In the above illustrative examples, the DNA files are stored locally in the
client computer even though the multimedia files referred to in the DNA
files could be remotely located. In another embodiment of the present
invention, the DNA files could be stored in a server. Client computers can
download appropriate DNA files from the server so as to create and execute
an application.
An embodiment of the present invention in a MS Windows environment is
described. Under MS Windows, it is possible to associate a file having a
predefined extension with a certain application. As an example, files
having the extensions "SFM" and "SFR" can be made to invoke a visual and a
run cell, respectively, operating under DCT. In one embodiment of the
present invention, all the DNA files are ASCII files. These DNA files
define an application through their own and link parameters. By
downloading these DNA files and invoking associated cells to a client
computer, the client computer can execute an application stored in a
server by transferring ASCII files (as opposed to program codes).
FIG. 5 is a schematic diagram illustrating distributable DNA files of the
present invention. The browser (not shown) of a client computer may
display a Web home page 830 which contains icons 832 and 834 indicating
downloadable DNA files. The HTML document (not shown) corresponding to
home page 830 contains "tags" which allows a browser to generate icons 832
and 834. In the present invention, these tags contain the URL of the DNA
files. When any one of these icons are clicked, the browser accesses its
own cache 835 to determine if the corresponding DNA file (for convenience
in this discussion, this DNA file is called the "home page DNA file") is
in cache 835. If it is in the cache, the browser can invoke the cell
associated with the DNA file (e.g., a visual cell) without the need for
downloading the file. If it is not in the cache, the browser causes the
DNA file to be downloaded from a server (e.g., server 840). The
corresponding cell is then invoked by the operating system based on the
extension of the downloaded DNA file.
As an example, icon 832 is linked to a DNA file called "DNA-1.SFR." Because
this file is not in browser cache 835, it is downloaded from server 840.
Once downloaded, the browser invokes a run cell 844. The characteristics
of the window associated with cell 844 is defined by DNA-1.SFR.
Note that up to this point, no URL cache is involved. This is because a URL
cache is invoked when a cell (instead of a web browser) attempts to
download a file. In this embodiment, a URL cache 836 would be used if the
DNA file of an associated cell makes reference to a second DNA file which
is located remotely. At that time, the procedure discussed above in
connection with FIG. 4 will be followed (i.e., the cell issues a command
to the internet resource loader, which in turn causes WinSock to download
a file, if there is a need to do so).
As an example, if cell 844 needs to access a remote DNA file (e.g.,
"DNA-2.SFR"), it asks URL cache 836 to obtain the file. If DNA-2.SFR is
not cached, it will be downloaded from a server (which could be in the
same server 840 or another server 842)
In a preferred embodiment of the present invention, all the home page DNA
files contain a "SFR" extension. Consequently, a run cell is invoked when
a user clicks on an icon associated with a downloadable DNA file. This
cell performs only one function: to download another DNA file (if not
present locally) and associate a corresponding cell (e.g., cell 846) to
the DNA file. This newly downloaded DNA file (e.g., DNA-2.SFR) is the real
DNA file of interest which contains the application designed by a
programmer. In this preferred embodiment, the home page DNA file can be
considered a phantom DNA file.
The reason for separating phantom DNA files from the real DNA files of
interest is that this arrangement allows users of the DCT technology to
review and edit all the DNA files under its control. As explained above,
the home page DNA files are cached by browser cache 835. Each browser uses
a proprietary cache design, and the files cached therein (e.g., DNA-1.SFR)
are generally outside the control of users and DCT. DCT can only control
files in URL cache 836. The above arrangement places all the real DNA
files of interest (e.g., DNA-2.SFR) in URL cache 836, and thus can be
controlled by DCT. As explained above, in one embodiment of the present
invention, the cache list and DNA files are written in ASCII form, thereby
allowing users to view and edit these files. Consequently, the users have
full control over their applications. On the other hand, the files cached
in the cache of the browser is generally not accessible by the user or
DCT.
Uploading Distributive DNA Files
In one embodiment of the present invention, all the DNA files are ASCII
files. Thus, it would be easy for a client computer to develop an
application using DCT technology and then send the associated DNA files
(and if needed, other files referred to in these DNA files) to a server.
Other client computers can then download these DNA files for executing the
application.
It should be noted that the servers are used in the present invention as a
convenient place to hold files. The present invention does not require the
use of a server. For example, a first client computer could send DNA files
to a second client computer, and the second computer could execute the
application. There is no need to have an intermediate computer (e.g., a
server) involved.
The present invention could be used by a group of programmers to develop
applications. As explained above in connection with FIG. 2, an application
may involve many cells, each associated with a DNA file. The development
of these DNA files could be assigned to several programmers working in
different client computers. These programmers upload their DNA files to a
server. A programmer in the server could integrate these DNA files into a
complex application. Alternatively, a programmer in a client computer can
download these files and integrate these files. The programmer then upload
the integrated application to the server. Client computers in the network
can download the DNA files of this complex application and execute it.
Detailed Description of the DCT
Conventional computer program architecture consists of a main program and a
plurality of program modules. The main program typically controls and
coordinates the operation of the program modules. FIG. 6 is a schematic
diagram of a program 100 having such an architecture. In FIG. 6, a main
program 102 contains a plurality of statements, such as 104 and 106. Some
of the statements could be CALL statements, such as statements 108 and
110. These two CALL statements, when executed, will invoke program modules
120 and 130. Main program 102 may contain a LOOP statement which causes
main program 102 to execute continuously in a loop. Main program 102 also
contains a STOP statement for terminating the program. It should be
appreciated that program 100 could be written in different programming
languages, and the precise syntax of the statements and program structure
could vary with the programming languages.
Program 100 contains a plurality of program modules, such as modules 120
and 130, called by main program 102. Module 120 contains a plurality of
statements, such as statements 122 and 124. It could also contain a
plurality of CALL statements, such as statement 126. This statement, when
executed, will invoke another module 140. Finally, module 120 contains a
RETURN statement.
When CALL statement 108 is executed, main program 102 jumps to module 120.
Statements 122, 124 and the rest of the program are executed. Upon
executing the RETURN statement in module 120, program 100 returns to
statement 106, which is the statement following CALL statement 108. At
this time, the control of program 100 is returned to main program 102.
Main program 102 continues to execute.
The structure of all the modules is similar to that of module 120.
Similarly, the jump-return mechanism, described above, is carried out by
all the CALL statements in program 100. Consequently, they will not be
further described in this specification.
In order to carry out this jump-return mechanism, the return addresses of
the CALL statements need to be saved in RAM (typically in a memory
structure called a stack). Other essential state information of the
computer prior to jumping to the called module, such as values of
registers, may also be saved if there is a need to do so (e.g., when
jumping to an interrupt service routine). Thus, when main program 102
calls module 120, the contents of these registers may also be pushed
(i.e., saved) in the stack. Similarly, when module 120 calls module 140,
the return address of module 120 also needs to be saved. The contents of
appropriate registers may need to be pushed in the stack. Thus, the size
of the stack could be large when a large number of CALL statements are
executed.
When a RETURN statement is executed, the return address is used to return
to the calling program. The saved information is also retrieved.
Typically, a program in the above described conventional architecture
contains many CALL statements and many modules. These modules could call
other modules (e.g., module 120 can call module 140), thereby forming a
chain of CALL statements. The precise history of this chain needs to be
preserved so that the last called module can return to the main program.
One of the problems of the conventional architecture is that the time to
travel the chain could be very long. As pointed out above, each time a
CALL statement is invoked, certain amount of state information needs to be
saved, resulting in overhead in execution. Each time a RETURN statement is
executed, the saved information needs to be restored, again requiring
overhead in execution. As a result, the execution speed of programs
written using conventional architecture is slow.
The following are some of the characteristics of the conventional
architecture: (a) there is a controlling ("boss") program, e.g., main
program 102, (b) all the linkage information (e.g., return address and
registers) needs to be preserved when one part of the program (a calling
program such as main program 102 or some of the modules) transfers
execution to another (the called program), and (c) the linkage information
is used to return control and information to the calling program. This
architecture could be called a "boss" architecture. The calling module can
be considered a master while the called module can be considered a slave
executing commands issued by the master and then reporting results to the
master.
Recently, other programming architectures have been developed. However,
they are also based on the boss architecture. One example is
object-oriented programming. This method allows codes to be reused and
applications developed relatively rapidly. However, the applications still
have a controlling body which adds tremendous overhead.
Advances in program architecture have also been made in operating
environments. One example is an interprocess communication protocol called
dynamic data exchange (DDE) used in Microsoft's MS Windows environment.
DDE uses a shared memory to exchange data between processes and a protocol
to synchronize the passing of data. The heart of DDE protocol is the DDE
message. A process (client) can ask another process (server) to perform a
service. Specifically, the client issues a WM.sub.-- DDE.sub.-- EXECUTE
message to post a command to the server by storing a command string in a
global memory block and passing to the server a handle to the global
memory block. The server subsequently returns a WM.sub.-- DDE.sub.-- ACK
message to the client. If the server successfully executes the command,
the WM.sub.-- DDE.sub.-- ACK message would return a TRUE value to a DDEACK
structure member labelled "fAck." If the command is not successfully
executed, the server posts a WM.sub.-- DDE.sub.-- ACK message with "fAck"
set to FALSE. When the client receives the WM.sub.-- DDE.sub.-- ACK
message from the server, it deletes the command string from global memory
and proceeds to take appropriate actions accordingly.
It is clear that interprocess communication via DDE has many
characteristics of the conventional architecture shown in FIG. 6.
Specifically, the preservation of linkage information and the return of
control to the client are important aspects of DDE. While the architecture
of FIG. 6 stores the content of a few registers and the return address in
each interprocess communication, DDE uses elaborate commands and data
structure. As a result, DDE is even less efficient than the architecture
of FIG. 6.
Another example of new developments in operating environment is an
architecture used in MS Windows called OLE (Object Linking and Embedding).
This architecture allows one application (e.g., a word processor program)
to be linked to one or more applications (e.g., a spreadsheet program). In
the terminology of OLE, applications can be classified as client
applications and server applications. MS Windows uses a "registration
database" to maintain a collection of information about OLE applications
and file extensions for MS Windows applications. All communication between
applications is handled by OLE. Specifically, OLE applications communicate
through the use of three dynamic-link libraries: OLECLI.DLL, OLESRV.DLL,
and SHELL.DLL. The SHELL.DLL enables applications to communicate with the
registration database. The OLECLI.DLL is the OLE client library and the
OLESRV.DLL is the server library. The OLE server and client libraries
communicate with each other through DDE messages. The typical path of
communication for an OLE function includes the call of the function, DDE
messages between OLE libraries, and disseminating information to the
client and server applications.
In one example, when the OLESRV.DLL library receives notificat | | |
