Browse Prior Art Database

Efficient run-time 'applet' for software update distribution in a network

IP.com Disclosure Number: IPCOM000015907D
Original Publication Date: 2002-Apr-15
Included in the Prior Art Database: 2003-Jun-21
Document File: 1 page(s) / 39K

Publishing Venue

IBM

Abstract

This proposal relates to the addition of information to be used in client-server interactions to ensure efficient and maximised client-side processing of an applet or similar. Currently, for XML, Java and so forth, a client device, such as PC or PDA etc., may request an application from a server. The server will then download to the device appropriate compiled code such that the application runs locally on the client side rather than at the host or server. Typically, there is a single compiled version of the executable at the server which is downloaded. Any programming efficiency gained from appropriate memory and CPU-cycle usage cannot be implemented, since the client-side device is unknown in advance to the server, and in consequence, either the lowest common denominator in terms of processing capacity at the client device has to be assumed, or some client devices will be unable to cater for the load required for the applet. Our proposal seeks to introduce the following elements: (1) multiple compiled versions of the appropriate executable to be stored at the server, optimised to different, typical processor environments at the client device; (2) a 'wrapper' of 'header' applet, whose function is detailed below; and (3), in one embodiment, the suitably secured source code at the server. When a client device requests the applet from the server, the wrapper applet is downloaded. Its function is solely to query the system resources of the receiving client device, and transmit this information back to the server. Using that information, the server selects the most appropriate version of the executable in (1) above, and transmits that for execution at the client device. The strategy at the server for selection could be (a) send the version that can be run fastest and most efficiently at the client device given the capacity of the client; or (b) send the version that by separate agreement should be provided to such devices; or both. An alternative or extension, under (3), would effect a quick compilation of the source code at the server given the characteristics identified by the wrapper applet at the client-device. In our proposal, the onus is on the wrapper applet to query and transmit suitable information (such as compilation options, and so forth) back to the server which would then download the appropriate (optimised) executable. It would also be possible, however, to implement at the protocol level (ie., just above the ftp/http/https or other communications layer) an explicit profile from the client during the initial request for the applet, or on the back of the wrapper applet itself, thus increasing the flexibility of the approach. The main benefit to be derived is more efficient system resource utilisation at the client device for distributed processing.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 1

Efficient run-time 'applet' for software update distribution in a network

This proposal relates to the addition of information to be used in client-server interactions to ensure efficient and maximised client-side processing of an applet or similar.

     Currently, for XML, Java and so forth, a client device, such as PC or PDA etc., may request an application from a server. The server will then download to the device appropriate compiled code such that the application runs locally on the client side rather than at the host or server. Typically, there is a single compiled version of the executable at the server which is downloaded. Any programming efficiency gained from appropriate memory and CPU-cycle usage cannot be implemented, since the client-side device is unknown in advance to the server, and in consequence, either the lowest common denominator in terms of processing capacity at the client device has to be assumed, or some client devices will be unable to cater for the load required for the applet. Our proposal seeks to introduce the following elements: (1) multiple compiled versions of the appropriate executable to be stored at the server, optimised to different, typical processor environments at the client device; (2) a 'wrapper' of 'header' applet, whose function is detailed below; and (3), in one embodiment, the suitably secured source code at the server.

     When a client device requests the applet from the server, the wrapper applet is downloaded. Its function...