« PrécédentContinuer »
U.S. Patent Dec. 7, 2010 Sheet 4 of 5
Q_ "D Z> CO
^: o 0) o
DYNAMICALLY UPDATING RENDERED
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to computer software, and deals more particularly with techniques for efficiently updating rendered content (such as content of a Web page) using a "slow-loading" content element (e.g., a slow-loading image). 10
2. Description of the Related Art
The popularity of computer networking environments has increased tremendously in recent years, due in large part to growing business and consumer use of the public Internet and the subset thereof known as the "Worldwide Web" (or simply 15 "Web"). Other types of computer networking environments, such as corporate intranets and extranets, are also increasingly popular. As solutions providers focus on delivering improved Web-based computing, many of the solutions which are developed are adaptable to other computer net- 20 working environments. Thus, references herein to the Internet and Web are for purposes of illustration and not of limitation. (Furthermore, the terms "Internet", "Web", and "World Wide Web" are used interchangeably herein.)
Most modern computing applications render their display- 25 able output using a graphical user interface, or "GUI". In a computer networking environment such as the Internet, client software known as a "browser" is typically responsible for requesting content from a server application and for rendering the information sent by the server in response. Com- 30 monly, the rendered information is formatted as a Web page, where the layout of the Web page is defined using a markup language such as Hypertext Markup Language ("HTML"). (References herein to rendered content are in terms of displayed HTML Web pages, although this is by way of illustra- 35 tion and not of limitation.)
Many client/server applications that operate in computer networking environments need to asynchronously update a GUI displayed on the client, based on (for example) some change in the server. Examples of this type of application 40 include system monitoring applications such as Tivoli Business Systems Manager and Tivoli Enterprise Console® (which may need to asynchronously display alert notifications to a system administrator); messaging/chat applications such as Lotus Sametime® (e.g., to display an indication of 45 which people on the user's instant messaging buddy list are currently available for instant messaging); and so forth. ("Tivoli Enterprise Console" is a registered trademark of International Business Machines Corporation and "Sametime" is a registered trademark of Lotus Development Cor- 50 poration.)
In the prior art, applications that need to asynchronously update a displayed GUI at a client typically use one of the following techniques to perform the update:
1) The client binds to a socket address and listens for 55 connections from the server. In this approach, the client starts
a listening thread attached to a socket. When an update occurs, the server creates a connection to the port where the client is listening, delivers the update notification, and then disconnects. 60
2) The client polls the server. In this approach, the client connects to the server periodically to check for updates, and then disconnects until the next polling interval. Typically, client polling results in downloading content without regard
to whether it has been updated. 65
3) The client maintains a persistent connection to the server. Here, the client connects to the server and "sub
scribes" to be notified of updates. When an update occurs, the server sends an update notification over this already-existing connection.
It is not possible to use the first technique listed above (where the client listens for server connections) without introducing a JavaTM applet, and using an applet in this way is often not possible since an applet that performs this type of privileged operation would require a cryptographic signature on the applet as well a hole in the client's firewall. When using the second technique listed above (where the client polls the server), a great deal of unnecessary network traffic can be generated, and the server can easily get overloaded. Client polling can also cause the GUI to flicker, and can interrupt the user's interactions with the Web page (since the page is suddenly and abruptly refreshed). These disadvantages often make the third technique listed above (use of a persistent connection) the most attractive. ("Java" is a trademark of Sun Microsystems, Inc.)
However, there are several problems with pushlets, several of which are described in the above-referenced white paper on pushlets. These problems include:
1) Interference from content buffering. The HTTP framework was not designed for persistent connections, so the content of an HTTP response is often buffered by some component of the network. Buffering may be introduced by an HTTP proxy server, network cache, or even the servlet
engine's HTTP server. This buffering can delay the client update, or even prevent it altogether.
2) No reconnect mechanism is available. Again, since the HTTP framework was not designed for persistent connections, the HTTP server and/or client often terminate an HTTP 5 request if it has been running for too long. It is also possible for the user to accidentally (or purposefully) terminate the persistent HTTP request by pressing the "Escape" key or the "Stop" button. When the HTTP request ends in this way, the client has no way to automatically reconnect the persistent 10 connection to the server, or to signal the user that he has caused a disconnect.
4) Cross-browser issues with DHTML support. While a standard version of DHTML is promulgated by the World Wide Web Consortium ("W3C"), different browser vendors 25 have provided their own unique extensions. These vendorspecific extensions complicate efforts to deploy pushlets uniformly across all browser platforms.
Accordingly, what is needed are improved techniques for asynchronously updating rendered content, while avoiding 30 drawbacks of prior art approaches.
SUMMARY OF THE INVENTION
An object of the present invention is to provide improved 35 techniques for asynchronously updating rendered content.
Another object of the present invention is to define techniques for more efficiently refreshing Web page content.
Still another object of the present invention is to define techniques for leveraging existing Web-based components to 40 dynamically update a rendered Web page.
Other objects and advantages of the present invention will be set forth in part in the description and in the drawings which follow and, in part, will be obvious from the description or may be learned by practice of the invention. 45
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention provides software-implemented methods, systems, and computer program products for asynchronously reloading dynamically-updateable content such as a Web 50 page. In one aspect of preferred embodiments, this technique comprises: embedding a reference to slow-loading content into markup notation for a Web page to be rendered; and specifying, with the reference, one or more event handlers that will automatically reload content into the Web page upon 55 occurrence of corresponding events. The reference to slowloading content may be an image element, an audio element, a video element, or other similar element encoded in the markup language notation. The event handlers may be specified as attributes of the element. The markup language may be 60 HTML or another markup language.
Typically, the automatically reloaded content is to be loaded into a dynamically-updateable portion of the Web page, and the Web page will be rendered on a client, according to its markup notation, causing delivery of the referenced 65 slow-loading content to begin (from a server that is connected to the client by a connection over a network).
The technique may further comprise: subsequently detecting, by the server, that the dynamically-updateable portion of the Web page should be updated; and terminating, by the server, the delivery of the slow-loading content, responsive to the detection, thereby triggering a corresponding event handler at the client.
Or, the technique may further comprise: subsequently detecting one of the events at the client (including interruption in delivery of the slow-loading content, a network error, a user interrupting delivery of the slow-loading content, or completion of delivery of the slow-loading content); and automatically triggering, by the client responsive to the subsequent detection, a corresponding event handler at the client.
In any case, the triggering of the event handler preferably further comprises automatically invoking, on the client, scripting logic that requests reloading the dynamically-updateable portion of the Web page. The technique may further comprise: receiving the reload request at the server; delivering, from the server to the client, a response containing new content that is responsive to the reload request, wherein the new content also embeds a reference to slow-loading content and specifies one or more event handlers; and rendering the new content from the delivered response at the client, wherein the rendering automatically sends a new request to the server for delivering the slow-loading content referenced in this new content.
Optionally, application properties and/or network properties may be used to adjust generation of the requested slowloading content before returning the generated slow-loading content over the network to the client.
In another aspect of preferred embodiments, the technique comprises: embedding a reference to slow-loading content into markup notation for content that is to be rendered, wherein at least a portion of the content to be rendered is dynamically-updateable; and specifying, with the reference, one or more event handlers that will automatically reload content into the dynamically-update portion of the rendered content upon occurrence of corresponding events. This technique may further comprise rendering the content on a target device, according to its markup notation, and beginning delivery of the referenced slow-loading content from a server that is communicatively connected to the target device. Preferably, the technique further comprises: subsequently detecting, at the client, that one of the events has occurred; and automatically requesting, by the corresponding event handler, that the slow-loading content be reloaded.
The target device may be (for example) a kiosk having a dynamically-updateable display, a device that provides a Web console having a dynamically-updateable display, or a device that renders information for a Web application.
The disclosed techniques may also be used advantageously in methods of doing business, whereby a service is offered to customers for delivering the slow-loading content elements on which preferred embodiments are based, and/or for deploying markup language content that invokes delivery of these slow-loading content elements. This service may be provided under various revenue models, such as pay-per-use billing, monthly or other periodic billing, and so forth. The advantages offered to clients over prior art techniques include more efficiently-refreshed content, more timely content, and/ or reduced network traffic.