Web Page Generation via Client State Synchronization
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Client/server applications, particularly web applications, face issues with controlling the uploading of local information to a server, leading to potential malfunctions and network overload when users reiterate requests during data transmission, especially with large data sets.
Innovation Solution
Implementing a method where a server entity manages the uploading process by sending a wait page with or without an upload command based on local information availability, using a back-end servlet to control the state attribute of data availability, and ensuring the wait page is self-refreshing and non-cachable to prevent redundant data transmission.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If the web application allows users to submit requests freely, then user interaction flexibility is improved, but network overload and malfunctions occur due to repeated uploading of local information
Solution Approach 1:
The system implements feedback by having the server check whether local information is already available before processing upload requests. The server returns appropriate responses (uploading in progress, already available, or not available) to guide client behavior, preventing redundant uploads while maintaining user interaction flexibility
Solution Approach 2:
The server performs preliminary checking of local information availability before allowing upload operations. By verifying the state attribute in advance, the system prevents redundant uploading actions from occurring, thereby avoiding network overload while preserving user request submission flexibility
2Loss of energy
If the server checks local information availability for every request, then redundant uploads are prevented, but system complexity increases due to state management requirements
Solution Approach 1:
The invention introduces a state attribute as an intermediary mechanism between the client and server. This simple binary state (available/not available) acts as a mediator that communicates upload status without requiring complex state management logic, efficiently reducing network bandwidth consumption while keeping the system relatively simple
Solution Approach 2:
The system uses a parameter change approach by maintaining a state attribute that transitions between two values (available/not available). This simple parameter change mechanism allows the server to track upload status efficiently without implementing complex state management systems, balancing network efficiency with system simplicity
3Loss of time
If the wait page is cached on the client, then page loading speed is improved, but redundant data transmission occurs when users navigate back and forward
Solution Approach 1:
The wait page is designed with dynamic characteristics by including a self-refreshing mechanism that periodically checks for updated content from the server. This dynamic behavior allows the page to load quickly from cache initially, then automatically refresh when new information is available, balancing loading speed with data freshness without causing redundant transmissions
Data Source
AI summary
The invention proposes a solution allowing a web application to generate a response page based on local information of a client. For this purpose, a front-end servlet (receiving a request from the browser of the client) verifies (318, 360) whether the local information is available on the server. If not, a wait page with a command for uploading the local information is generated and sent (321) to the client, so as to cause the client to transmit (327-342) the local information to a back-end servlet of the server. The wait page self-refreshes (348-357) after a predefined delay; in response thereto, the same front-end servlet verifies whether the local information is ready to use. If the uploading is still in progress, a wait page without the upload command (which self-refreshes after the same delay) is generated and sent (363) again. Once the uploading has been completed, the front-end servlet can generate and send (366-372) the desired response page based on the up-to-date local information of the client.