Abstract: A computing device provides a first server. The first server receives a primary request associated with a client. In response to receiving the primary request, the first server processes the primary request to generate a response message. As part of processing the primary request, the first server sends a secondary request to a second server after a delay period expires. The second server accesses a resource as part of processing of the secondary request. The duration of the delay period depends at least in part on a recent latency level of the client with regard to the resource. In this way, the first server throttles access to the resource.

Abstract: A computing device provides a first server. The first server receives a primary request associated with a client. In response to receiving the primary request, the first server processes the primary request to generate a response message. As part of processing the primary request, the first server sends a secondary request to a second server after a delay period expires. The second server accesses a resource as part of processing of the secondary request. The duration of the delay period depends at least in part on a recent latency level of the client with regard to the resource. In this way, the first server throttles access to the resource.

Abstract: A computing device provides a first server. The first server receives a primary request associated with a client. In response to receiving the primary request, the first server processes the primary request to generate a response message. As part of processing the primary request, the first server sends a secondary request to a second server after a delay period expires. The second server accesses a resource as part of processing of the secondary request. The duration of the delay period depends at least in part on a recent latency level of the client with regard to the resource. In this way, the first server throttles access to the resource.

Abstract: A server push model for client/server communications. The push architecture operates on top of a non-push (e.g., request/response) protocol (e.g., HTTP) to combine notifications from multiple data sources (e.g., email, text messaging, etc.). The server can be a middle-tier server (or proxy) to which a single web client registers interest in one or more notification types from one or more data sources. The mid-tier server aggregates the notifications from the various data sources and delivers the notifications to the requesting client via a single “push” pipe. The web client then distributes each notification to the appropriate parts of the client user interface. A producer/consumer locking mechanism eliminates blocking threads waiting on a mutual exclusion lock. A notification throttling mechanism distinguishes different types of notifications in order to guarantee that the client is not overloaded with too much information.

Abstract: A server push model for client/server communications. The push architecture operates on top of a non-push (e.g., request/response) protocol (e.g., HTTP) to combine notifications from multiple data sources (e.g., email, text messaging, etc.). The server can be a middle-tier server (or proxy) to which a single web client registers interest in one or more notification types from one or more data sources. The mid-tier server aggregates the notifications from the various data sources and delivers the notifications to the requesting client via a single “push” pipe. The web client then distributes each notification to the appropriate parts of the client user interface. A producer/consumer locking mechanism eliminates blocking threads waiting on a mutual exclusion lock. A notification throttling mechanism distinguishes different types of notifications in order to guarantee that the client is not overloaded with too much information.

Abstract: A server push model for client/server communications. The push architecture operates on top of a non-push (e.g., request/response) protocol (e.g., HTTP) to combine notifications from multiple data sources (e.g., email, text messaging, etc.). The server can be a middle-tier server (or proxy) to which a single web client registers interest in one or more notification types from one or more data sources. The mid-tier server aggregates the notifications from the various data sources and delivers the notifications to the requesting client via a single “push” pipe. The web client then distributes each notification to the appropriate parts of the client user interface. A producer/consumer locking mechanism eliminates blocking threads waiting on a mutual exclusion lock. A notification throttling mechanism distinguishes different types of notifications in order to guarantee that the client is not overloaded with too much information.

Abstract: A computing device provides a first server. The first server receives a primary request associated with a client. In response to receiving the primary request, the first server processes the primary request to generate a response message. As part of processing the primary request, the first server sends a secondary request to a second server after a delay period expires. The second server accesses a resource as part of processing of the secondary request. The duration of the delay period depends at least in part on a recent latency level of the client with regard to the resource. In this way, the first server throttles access to the resource.

Abstract: A virtual list view in a web application is dynamically updated such that a user can seamlessly access and manage the presented data despite the inherent latency involved with the web. Data associated with the virtual list view is downloaded in chunks and the view updated as the user scrolls. By coupling the user's scrolling and particular chunks of data to be downloaded system resources are utilized in an efficient manner. Additional user interface controls for the user interface are employed for rapid and efficient access to portions of data minimizing delay and system resource occupation.

Abstract: A server push model for client/server communications. The push architecture operates on top of a non-push (e.g., request/response) protocol (e.g., HTTP) to combine notifications from multiple data sources (e.g., email, text messaging, etc.). The server can be a middle-tier server (or proxy) to which a single web client registers interest in one or more notification types from one or more data sources. The mid-tier server aggregates the notifications from the various data sources and delivers the notifications to the requesting client via a single “push” pipe. The web client then distributes each notification to the appropriate parts of the client user interface. A producer/consumer locking mechanism eliminates blocking threads waiting on a mutual exclusion lock. A notification throttling mechanism distinguishes different types of notifications in order to guarantee that the client is not overloaded with too much information.

Abstract: A virtual list view in a web application is dynamically updated such that a user can seamlessly access and manage the presented data despite the inherent latency involved with the web. Data associated with the virtual list view is downloaded in chunks and the view updated as the user scrolls. By coupling the user's scrolling and particular chunks of data to be downloaded system resources are utilized in an efficient manner. Additional user interface controls for the user interface are employed for rapid and efficient access to portions of data minimizing delay and system resource occupation.