Detachable java applets

Details Detachable java applets Detachable java applets

1997-07-25

2002-06-04

Dinh, Dung C. (Department: 2153)

Electrical computers and digital processing systems: multicomput

Computer-to-computer data routing

Least weight routing

C345S215000

Reexamination Certificate

active

06401134

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to the field of computer software. More specifically, the present invention relates to applets and their relationship to an operating environment.
2. Description of Related Art
Recent versions of applications such as browsers like Netscape Navigator 3.0™ or Hot Java™ (a product of Sun Microsystems, the Sun logo and Hot Java are trademarks or registered trademarks of Sun Microsystems in the United States and other countries) have provided for the use of platform-independent “applets” which can be downloaded as pre-compiled Java byte-codes (intermediate level instructions). These applets are executed via a “virtual machine,” which is a platform-specific environment that interprets or compiles the applet code and performs the high-level instructions therein. One popular and predominant applet programming language, developed by Sun Microsystems, Inc., is known as “Java™” (a product of Sun Microsystems, the Sun logo and Java are trademarks or registered trademarks of Sun Microsystems in the United States and other countries). Applets programmed in Java or minor variations thereof are referred to as Java applets.
The key usefulness of Java applets is that they are platform-independent, i.e., a Java applet written for platform A will run without modification on platform B provided that both platform A and platform B have virtual machines capable of executing applet code for their respective platforms. Even though Java applets are platform-independent, the characteristics, quirks and limitations of the applications from which they are spawned weaken the flexibility by causing the applets to become essentially “application-dependent.” For example, one limitation of Java applets when called from HTML (Hypertext Markup Language) code for the Sun operating system version of Netscape Navigator is that when applets are called, the HTML tag for the call must include a height and width, thus defining a window size that the applet must execute within. When running inside the application window, the applet is constrained by the stated height and width tag and thus, any output, input, dialog boxes or pop-up windows that are generated for the applet must appear within that constraint.
In this situation, where the applet window is a “sub-window” of the application window, the applet window suffers several impediments. First, the applet window cannot be closed unless the application is quit or until the application transitions to receive data from a new host (in the same window that launched (spawned) the applet). And concomitant with that limitation, when the application that spawned the applet transitions to a new URL (Uniform Resource Locator—the “address” of the host visited by the application) then the applet window closes and the applet ceases execution. The cessation of the applet is out of the control of the user. In certain instances, it is desirable to continue running the applet even though the application has transitioned to a different URL. For instance, a user may desire a streaming audio applet that plays content from an external or remote source which is launched from URL A to continue playing even though the application has proceeded to URL B, which does not have the same applet. Under current practice, it would be necessary to open or spawn a new instance of the application (i.e., open a new application window) to receive its content from URL B so that the other application instance continues to play the audio applet. But this approach suffers from several maladies.
First, launching a new application instance may involve an increase in memory and system resource utilization which will diminish the performance of both the applet and the new application instance. Further, the applet still cannot be controlled outside of the constraints or environment of the application. In fact, with a second application window (instance) launched, the first window must become active (in the foreground, under control of cursor or mouse) before the applet can be controlled. Further, the traditional applet model does not allow for iconification of the applet window within the operating environment (minimizing of the window). Under current practice, the application window itself must be minimized in order to minimize and iconify the applet. In that case, the applet rather than having its own icon, will the inherit the icon of the browser. The lack of window minimization, resizing and other GUI modification such as changing fonts, backgrounds colors, etc., imposes severe constraints on the applet to be independently controlled without application constraints.
One solution to remove the application dependence of executable code modules has been the use of “plug-ins”. However, unlike “plug-ins” (file(s) containing data/code used to alter, enhance, or extend the operation of a parent application) that are operating environment/platform specific, Java applets are essentially platform independent. Plug-ins, which must be downloaded (or come packaged with the application), allow certain file types (such as Shockwave™ or RealAudio™) which may not be supported internally by the application to be interpreted and output on the local platform. However, plug-ins are disadvantageous in that they remain resident locally and must be stored on local disk for re-use, unlike the virtual machine of Java which is application resident. Importantly, plug-ins spawn processes wholly independent of the browser and are thus, platform dependent. Thus, though plug-ins may allow for independent GUI control of their windows, they are completely disinherited from the browser unlike Java applets (because they do not require a virtual machine to run). Running a plug-in is akin to running a separate application via the operating environment, and thus is not a viable substitute for portable executability as is a Java applet.
Yet another development for enhancing capabilities of an application such as a browser is the use of “helper” applications. Helper applications, which are stored locally, do not have the portability and platform independence of Java applets, i.e., a helper application on a Pentium platform cannot be used on a Sun Sparc™ (a product of Sun Microsystems, the Sun logo and Sparc are trademarks or registered trademarks of Sun Microsystems in the United States and other countries) system or vice-versa. The helper application also spawns a new process/thread within the operating environment and commands the system resources of a new application instance which is unlike Java applets. The helper application is not related to the application delivering the data to be processed and is merely called through the operating environment. The helper application does not plug-in or execute within a virtual machine of the application. Further, a helper application is not easily transferred from host to client, since helper applications can be quite large in code size when compared to applets.
Further, on newer information devices such as network computers (NCs), helper applications and plug-ins may not even work due to limited operating environment features and lack of local storage. NCs are conceptually based on utilizing remotely stored applets, such as Java applets which are network distributed, to provide applications and content to the NC. In contrast, the current industry standard for NCs guarantees that NCs are able to execute Java applets, through the use of virtual machine and browser/application. Even in the NC situation, it is desirable that the applet have its own built-in functionality separate from the browser/application from which it is called.
Thus, there is a need for a method and apparatus to detach Java applets from the constraints of the application so that they can be GUI-controlled directly through the operating environment and so that they not be limited by the state of the application in which the applets are spawned.
SUMMARY
A method and system is disclosed for detaching Java applets from the constraints of the application whic

Affiliated with

Also associated with

Rating

Detachable java applets does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Detachable java applets, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Detachable java applets will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2935560