Browse Prior Art Database

Portal Cooperative Disconnected Client

IP.com Disclosure Number: IPCOM000015916D
Original Publication Date: 2002-Sep-08
Included in the Prior Art Database: 2003-Jun-21
Document File: 2 page(s) / 43K

Publishing Venue

IBM

Abstract

As more and more users of portals become mobile, the notion of a portal disconnected client becomes an important consideration. Portals of today rely on the user being constantly connected. They do not and cannot deliver function when the user is disconnected from the portal.

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

Page 1 of 2

Portal Cooperative Disconnected Client

    As more and more users of portals become mobile, the notion of a portal disconnected client becomes an important consideration. Portals of today rely on the user being constantly connected. They do not and cannot deliver function when the user is disconnected from the portal.

This disclosure introduces a notion and set of processes for a disconnected HTTP daemon based client that is has high synergy and cooperation with a portal server. We'll abbreviate the client as the poco client (POrtal COperatve client).

The poco client is installed in the user's client device as an HTTP daemon. The poco client fields all HTTP requests made by the client device browser to a portal server. In the case where the client device is not currently connected to a portal server, the poco client determines this. Instead of passing the HTTP request to the portal server the poco client responds to the HTTP request, building an HTTP response to be returned to the client.

The Poco client builds this response by building an aggregation of markup. The aggregation is assembled by combining a static outer document of markup with a call to a plurality of interface modules called "disconnect-lets". These disconnect-lets are responsible for representing a portlet that resides on the portal server. They produce markup that is combined into the outer document of markup. This aggregated document is returned to the browser device in lieu of a real portal page in the case where the portal is not connected to the client.

The outer document can include markup that conveys portal branding and user interface. Markup can also be included could trigger a disconnect-let, on a subsequent event, to call the appropriate API's to get the client device connected to the Internet and the portal server.

The disconnect-lets can also provide more direct interfaces to other client side applications such as messaging and notifications. These may be surfaced through the portal when the user is connected to the portal, but surfaced through the disconnect-let when the portal is not connected. An example of this is a chat portlet. When the user is connected to the portal, the chat portlet displays a standard U/I and the user interacts with it. When the user disconnects from the portal the disconnect-let representing chat takes over and begins interacting with the device's two way pager card, retrieving chat message via two way pa...