Low-latency, incremental rendering in a content framework

• US 20040205555A1
• Filed: 09/18/2001
• Published: 10/14/2004
• Est. Priority Date: 09/18/2001
• Status: Active Grant

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Hind, John R., Schaeck, Thomas, Topol, Brad B.
• Granted Patent: US 7,346,843 B2
• Time in Patent Office: Days
• US Class Current: 715/513
• CPC Class Codes: G06F 16/954 Navigation, e.g. using categorised browsing
• CPC Class Codes: G06F 16/958 Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
• CPC Class Codes: H04L 67/02 based on web technology, e.g. hypertext transfer protocol [HTTP]
• CPC Class Codes: H04L 69/329 in the application layer [OSI layer 7]

Abstract

Techniques are disclosed for incrementally rendering content in a content framework (such as a portal page provided by a portal system). Upon receiving a request for a portal page, a portal server immediately returns a response including the results from portlets which have acquired their content. If some portlets have not yet finished, subsequent content is delivered at a later time through use of one of several alternative programmatically-generated mechanisms. Capabilities of existing browsers are leveraged for several embodiments, including use of refresh headers, multipart MIME (“Multi-purpose Internet Mail Extensions”) types, and portal pages structured using frames.

Claims

1. A method of incrementally rendering content in a content framework, comprising steps of:

receiving a request for a portal page, wherein one or more portlets provide content for the portal page;

immediately returning a response message containing a first document, the first document representing results from portlets which have acquired their content; and

programmatically generating a mechanism for delivering an updated document if the first document does not represent results of all portlets.

2. The method according to claim 1, wherein the programmatically generated mechanism comprises inclusion of a refresh trigger in the response message.

3. The method according to claim 2, wherein the refresh trigger is a refresh header of the response message.

4. The method according to claim 2, wherein the refresh trigger is encoded using syntax of a markup language.

5. The method according to claim 4, wherein the markup language is HTML (“

Hypertext Markup Language”

).

6. The method according to claim 5, wherein the syntax comprises a “

META”

tag using an “

HTIP-EQUIV”

attribute syntax.

7. The method according to claim 4, wherein the markup language is WML (“

Wireless Markup Language”

).

8. The method according to claim 4, wherein the markup language is i-mode format.

9. The method according to claim 4, wherein the markup language is HDML (“

Handheld Device Markup Language”

).

10. The method according to claim 2, wherein a value on the refresh trigger specifies a time before which the programmatically generated mechanism does not execute.

11. The method according to claim 2, wherein a value on the refresh trigger is computed as a time after which a sender of the portal page request automatically invokes the delivery of the updated document.

12. The method according to claim 2, wherein a value on the refresh trigger is computed as a latest predicted completion time of a final one of the portlets which have not yet acquired their content.

13. The method according to claim 12, wherein the value is determined by weighting actual fetch times of the portlets which have not yet acquired their content.

14. The method according to claim 12, wherein the value is determined by adding a constant value to a largest of weighted actual fetch times of the portlets which have not yet acquired their content.

15. The method according to claim 2, further comprising steps of:

receiving the response message by a client from which the request for the portal page was sent;

rendering, by the client, the first document from the received response message; and

automatically sending a subsequent request for the portal page after waiting for a time specified by a value of the refresh trigger.

16. The method according to claim 2, further comprising steps of:

receiving a subsequent request for the portal page, the subsequent request having been automatically sent responsive to receiving the refresh trigger; and

returning a subsequent response comprising the updated document, responsive to receiving the subsequent request, the updated document being a subsequent version of the first document and representing results from portlets which have acquired their content thus far and which omits the refresh trigger only if all portlets have now acquired their content.

17. The method according to claim 1, wherein the programmatically generated mechanism comprises creating a multipart document, and wherein the first document is embedded in a first of the parts of the multipart document.

18. The method according to claim 17, wherein the first of the parts is preceded by a boundary string used to delimit parts of the multipart document.

19. The method according to claim 18, wherein the first of the parts is followed by a terminating boundary string if the first document represents results from all portlets.

20. The method according to claim 17, further comprising steps of:

receiving the response message by a client from which the request for the portal page was sent;

rendering, by the client, the first document from the first of the parts of the multipart document;

receiving, by the client, subsequent parts of the multipart document, each of the subsequent parts comprising a revised version of the first document; and

rendering, by the client, the subsequent parts of the multipart document.

21. The method according to claim 17, further comprising steps of:

detecting that one or more of the portlets which had not acquired their content when the first document was returned in the response message have now acquired their content; and

sending, responsive to the detecting step, a subsequent response message containing a revised version of the first document, the revised version representing results from the one or more portlets and being embedded in a subsequent part of the multipart document.

22. The method according to claim 21, wherein the subsequent part is preceded by a boundary string used to delimit parts of the multipart document and is followed by a terminating boundary string if the revised version represents results from all portlets.

23. The method according to claim 1, wherein the programmatically generated mechanism comprises programmatically inserting a hyperlink into the first document, wherein the inserted hyperlink can be used to explicitly request delivery of the updated document.

24. A method of incrementally rendering content in a content framework, comprising steps of:

receiving a request for a portal page, wherein one or more portlets provide content for the portal page;

immediately returning a response message containing a first document, the first document representing results from portlets which have acquired their content; and

automatically delivering an updated document if the first document does not represent results of all portlets.

25. A method of incrementally rendering content in a content framework, comprising steps of:

receiving a request for a portal page frame, wherein one or more portlets provide content for the portal page frame;

immediately returning a response message containing a first mini-document, the first document representing results from portlets which have acquired their content; and

programmatically generating a mechanism for delivering an updated mini-document if the first mini-document does not represent results of all portlets.

26. The method according to claim 25, wherein the programmatically generated mechanism comprises inclusion of a refresh header in the response message.

27. The method according to claim 25, wherein the programmatically generated mechanism comprises inclusion of an syntax element in the response header, wherein the syntax element is encoded using a markup language.

28. The method according to claim 27, wherein the markup language is HTML (“

Hypertext Markup Language”

) and the syntax element comprises a “

META”

tag using an “

HTTP-EQUIV”

attribute syntax.

29. The method according to claim 26, wherein a value on the refresh header is computed as a time after which a sender of the portal page frame request automatically invokes the delivery of the updated mini-document.

30. The method according to claim 25, wherein the programmatically generated mechanism comprises creating a multipart document, and wherein the first mini-document is embedded in a first of the parts of the multipart document.

31. The method according to claim 30, wherein the first of the parts is preceded by a boundary string used to delimit parts of the multipart document, and is followed by a terminating boundary string if the first mini-document represents results from all portlets.

32. A system for incrementally rendering content in a content framework, comprising:

means for receiving a request for a portal page, wherein one or more portlets provide content for the portal page;

means for immediately returning a response message containing a first document, the first document representing results from portlets which have acquired their content; and

means for programmatically generating a mechanism for delivering an updated document if the first document does not represent results of all portlets.

33. The system according to claim 32, wherein the programmatically generated mechanism comprises inclusion of a refresh trigger in the response message.

34. The system according to claim 32, further comprising:

means for receiving the response message by a client from which the request for the portal page was sent;

means for rendering, by the client, the first document from the received response message; and

means for automatically sending a subsequent request for the portal page after waiting for a time specified by a value of the refresh trigger.

35. The system according to claim 32, further comprising:

means for receiving a subsequent request for the portal page, the subsequent request having been automatically sent responsive to receiving the refresh trigger; and

means for returning a subsequent response comprising the updated document, responsive to receiving the subsequent request, the updated document being a subsequent version of the first document and representing results from portlets which have acquired their content thus far and which omits the refresh trigger only if all portlets have now acquired their content.

36. The system according to claim 32, wherein the programmatically generated mechanism comprises creating a multipart document, and wherein the first document is embedded in a first of the parts of the multipart document.

37. The system according to claim 36, wherein the first of the parts is preceded by a boundary string used to delimit parts of the multipart document, and is followed by a terminating boundary string only if the first document represents results from all portlets.

38. The system according to claim 36, further comprising:

means for receiving the response message by a client from which the request for the portal page was sent;

means for rendering, by the client, the first document from the first of the parts of the multipart document;

means for receiving, by the client, subsequent parts of the multipart document, each of the subsequent parts comprising a revised version of the first document; and

means for rendering, by the client, the subsequent parts of the multipart document.

39. The system according to claim 36, further comprising:

means for detecting that one or more of the portlets which had not acquired their content when the first document was returned in the response message have now acquired their content; and

means for sending, responsive to the means for detecting, a subsequent response message containing a revised version of the first document, the revised version representing results from the one or more portlets and being embedded in a subsequent part of the multipart document.

40. The system according to claim 39, wherein the subsequent part is preceded by a boundary string used to delimit parts of the multipart document and is followed by a terminating boundary string if the revised version represents results from all portlets.

41. The system according to claim 32, wherein the programatically generated mechanism comprises programmatically inserting a hyperlink into the first document, wherein the inserted hyperlink can be used to explicitly request delivery of the updated document.

42. A system for incrementally rendering content in a content framework, comprising:

means for receiving a request for a portal page frame, wherein one or more portlets provide content for the portal page frame;

means for immediately returning a response message containing a first mini-document, the first document representing results from portlets which have acquired their content; and

means for programmatically generating a mechanism for delivering an updated mini-document if the first mini-document does not represent results of all portlets.

43. The system according to claim 42, wherein the programmatically generated mechanism comprises inclusion of a refresh header in the response message.

44. The method according to claim 42, wherein the programmatically generated mechanism comprises inclusion of an syntax element in the response header, wherein the syntax element is encoded using a markup language.

45. The system according to claim 42, wherein the programmatically generated mechanism comprises creating a multipart document, and wherein the first mini-document is embedded in a first of the parts of the multipart document.

46. A computer program product incrementally rendering content in a content framework, the computer program product embodied on one or more computer-usable media and comprising:

computer readable program code means for receiving a request for a portal page, wherein one or more portlets provide content for the portal page;

computer readable program code means for immediately returning a response message containing a first document, the first document representing results from portlets which have acquired their content; and

computer readable program code means for programmatically generating a mechanism for delivering an updated document if the first document does not represent results of all portlets.

47. The computer program product according to claim 46, wherein the programmatically generated mechanism comprises inclusion of a refresh trigger in the response message.

48. The computer program product according to claim 46, further comprising:

computer readable program code means for receiving the response message by a client from which the request for the portal page was sent;

computer readable program code means for rendering, by the client, the first document from the received response message; and

computer readable program code means for automatically sending a subsequent request for the portal page after waiting for a time specified by a value of the refresh trigger.

49. The computer program product according to claim 46, further comprising:

computer readable program code means for receiving a subsequent request for the portal page, the subsequent request having been automatically sent responsive to receiving the refresh trigger; and

computer readable program code means for returning a subsequent response comprising the updated document, responsive to receiving the subsequent request, the updated document being a subsequent version of the first document and representing results from portlets which have acquired their content thus far and which omits the refresh trigger only if all portlets have now acquired their content.

50. The computer program product according to claim 46, wherein:

the programmatically generated mechanism comprises creating a multipart document;

the first document is embedded in a first of the parts of the multipart document;

the first of the parts is preceded by a boundary string used to delimit parts of the multipart document; and

the first of the parts is followed by a terminating boundary string only if the first document represents results from all portlets.

51. The computer program product according to claim 50, further comprising:

computer readable program code means for receiving the response message by a client from which the request for the portal page was sent;

computer readable program code means for rendering, by the client, the first document from the first of the parts of the multipart document;

computer readable program code means for receiving, by the client, subsequent parts of the multipart document, each of the subsequent parts comprising a revised version of the first document; and

computer readable program code means for rendering, by the client, the subsequent parts of the multipart document.

52. The computer program product according to claim 50, further comprising:

computer readable program code means for detecting that one or more of the portlets which had not acquired their content when the first document was returned in the response message have now acquired their content; and

computer readable program code means for sending, responsive to the computer readable program code means for detecting, a subsequent response message containing a revised version of the first document, the revised version representing results from the one or more portlets and being embedded in a subsequent part of the multipart document.

53. The computer program product according to claim 52, wherein the subsequent part is preceded by a boundary string used to delimit parts of the multipart document and is followed by a terminating boundary string only if the revised version represents results from all portlets.