RE: [wsrp-coord] A few questions regarding the current semantics doc

Currently, I think it’s a three step process:

pbia() call to create the event
handleEvents() call to distribute the event
getMarkup() calls to render the portlets

The data use case suggests that this can possibly be reduced to a one step through a new form of non-opaque state shared amongst all portlets on the page. This state is carried within a request parameter within the “sales region” URL’s. The parameter is then set within a field on the MarkupParams. This form of sharing would reduce the process to only the getMarkup() call.

I’m not quite sure I understand what you mean when you say, “The assumption here is that all the portlets in the page are equal, so you can not assume the “change sales region” is somehow especially “near” the consumer.” Could you clarify?

Scott

From: Tamari, Yossi [mailto:yossi.tamari@sap.com]
Sent: Sunday, May 09, 2004 4:13 AM
To: wsrp-coord@lists.oasis-open.org
Subject: RE: [wsrp-coord] A few questions regarding the current semantics doc

Hi Scott,

Regarding 1, I think we all agree this is a common use case, perhaps the most common one. However, I don’t see how it can be solved generally in a more performant manner, in a WSRP environment. Specifically, I don’t see the how using the “initial state” direction can solve this.

The assumption here is that all the portlets in the page are equal, so you can not assume the “change sales region” is somehow especially “near” the consumer.

Can you explain how you would optimize this? (Currently it is a two step process, where the second step involves multiple WS requests in parallel, so an optimization would probably require making it a single step process.)

Yossi.

From: Goldstein, Scott [mailto:Scott.Goldstein@vignette.com]
Sent: Friday, May 07, 2004 3:25 AM
To: wsrp-coord@lists.oasis-open.org
Subject: [wsrp-coord] A few questions regarding the current semantics doc

I have a few questions regarding the current eventing semantics document. These are all items which have been discussed before I joined the TC, so I apologize if I'm simply missing information which has already been presented.

1. The data use case written up by Mike has been translated into goal 4 of the document. The goal states that the data use case only applies to the initial state of the portlet. It's not clear to me, though, why this limitation has been set. Consider the following example:

There are several portlets on a page which comprise a composite application to share company sales information. One portlet contains a set of links for all of the sales regions in the company. When a user selects a sales region in this portlet, the rest of the portlets on the page display some specific information about the selected sales region.

Though I agree that this example can be implemented using the current eventing framework, I don't feel that it can be done in an ideal fashion. It would require a pbia() call when selecting a sales region and additional calls for each portlet to distribute the resulting event. This is a lot of overhead, considering all that’s needed is to pass a sales region id to all of the portlets on the page. This seems like a common portlet coordination use case which should, ideally, be handled in an efficient manner. Do others agree? Does it, therefore, make sense to expand goal 4 beyond just the initial state of the portlet? Or, am I incorrectly interpreting the term, "initial state"?

2. Besides the use case presented by Mike, are there any other documented use cases which are being used as input to the document? The other URL listed seems to describe a general business scenario rather than concrete portlet coordination use cases.

3. What are the use cases for returning a new Portlet Mode and Window State from handleEvents()? I’m guessing that this may still be under discussion, since the document still has question marks for these two return fields.

4. What happens when two portlets return the Maximized window state? Does section 3.2.3 come into play here? Is it up to the portal to decide? This issue seems similar to the redirectURL problem discussed last week.

Thanks for the information.

Scott

wsrp-coord message