Virtualizing Extension Code in Web Applications

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing web applications face performance degradation and resource inefficiency due to the consumption of resources by multiple extensions running simultaneously, which can reduce user experience and operating efficiency.

Innovation Solution

The approach involves virtualizing extension code by loading only metadata initially and delaying the loading of implementation code until user interaction occurs, allowing only necessary extensions to run and reducing memory and processor cycles usage.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If multiple extensions are loaded and run simultaneously to enhance application functionality, then the functionality and versatility of the application is improved, but the resource consumption (memory, processing cycles, network) increases and user experience deteriorates

Engineering Contradiction:
Improveapplication functionalityVSAvoidresource consumption
Core Design Contradiction:
Adaptability or versatilityVSQuantity of substance

Solution Approach 1:

The patent applies preliminary action by loading extension metadata before the actual extension code. The portal loads extension metadata during initialization to prepare for potential extension loading, but the full extension implementation code is only loaded when actually needed. This allows the system to be ready to support multiple extensions without immediately consuming their resources, resolving the contradiction between functionality availability and resource consumption.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent implements dynamics by making extension loading dynamic rather than static. Extensions are not loaded at fixed points (like startup) but are dynamically loaded based on user interactions and portal state. The system transitions between having extensions available in metadata form and having them fully loaded in memory, allowing flexibility in resource allocation while maintaining functionality when needed.

Inventive Principle:
Principle #15Dynamics

2Reliability

If extension code is loaded immediately upon portal loading to ensure functionality, then the reliability and responsiveness of extension features is improved, but the initial loading time and memory usage increases

Engineering Contradiction:
Improveextension functionality reliabilityVSAvoidloading time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system performs preliminary action by loading extension metadata during portal initialization, which is a lightweight operation compared to loading full extension code. This preliminary metadata loading ensures that the system is prepared to load extensions quickly when needed, maintaining reliability without the time penalty of loading all extensions upfront. The metadata contains sufficient information to identify and load specific extensions on demand.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent treats extension metadata as a cheap, lightweight representation that can be loaded quickly and discarded or kept in memory efficiently. Rather than loading heavy extension code immediately, the system uses the lightweight metadata as a placeholder that can be replaced with full extension code only when that specific extension is actually activated by user interaction, reducing both initial loading time and persistent memory usage.

Inventive Principle:
Principle #27Cheap short-living objects (Disposable)

3Ease of operation

If all extension code is loaded into memory to support user interactions, then the responsiveness to user actions is improved, but the memory consumption and operating efficiency deteriorates

Engineering Contradiction:
Improveuser interaction responsivenessVSAvoidmemory consumption
Core Design Contradiction:
Ease of operationVSUse of energy by moving object

Solution Approach 1:

The patent applies segmentation by dividing extension code into separate, independently loadable units. Rather than loading all extension code as a monolithic block, the system segments extensions so that only the specific extension code needed for the current user interaction is loaded into memory. This segmentation allows the portal to maintain responsiveness by having individual extensions readily available while keeping overall memory consumption low by not holding all extensions in memory simultaneously.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system implements dynamic extension loading where extension code is loaded into memory only when a user interaction triggers its need. The memory state of extensions is dynamic - extensions transition from being represented as metadata on disk to being loaded as active code in memory based on real-time user behavior. This dynamic approach ensures responsiveness to user actions while optimizing memory consumption by having extensions in memory only when actively needed rather than persistently loaded.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentUS10678561B2Virtualizing extension code in an application
Publication Date: 2020.06.09 MICROSOFT TECHNOLOGY LICENSING LLC
  • US10678561B2 patent drawing
  • US10678561B2 patent drawing
  • US10678561B2 patent drawing

AI summary

Techniques are described herein that are capable of virtualizing extension code (e.g., third-party extension code) in an application (e.g., a web application in a browser). A portal of an application is loaded. The portal has an extensibility point via which an extension is to enhance functionality of the application. The extension includes metadata and implementation code. A functionality that the implementation code is configured to provide with regard to the application is automatically determined. The metadata is automatically generated to indicate the functionality in response to the functionality being automatically determined. The metadata is loaded in response to the portal being loaded. Loading of the implementation code is delayed until an interaction indicator is received, in response to loading the metadata. The interaction indicator indicates that a user interaction occurs. The implementation code is loaded based at least in part on receipt of the interaction indicator.