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

[Rich Thompson <richt2@us.ibm.com>]

1. The reason goal 4 appears as the
only goal linked to the data use case is that accepting this use case required
adding this goal. One of the current tasks (Mike accepted leading this
one and I'm sure would accept any offered assistance) is evaluating how
well the current semantics match the data use case. I think performance
is one of the key questions this review should consider.

2. The use cases the TC defined when
it was first getting going where required to start with a business use
case to ensure that we didn't just head down technically interesting directions
that had no relevance to the marketplace. The Multimedia Sports Portal
use case required coordination between the portlets and the review setting
the direction for v2 established this as a base that captured the key needs
to address first.

3. These are under discussion ... they
were initially added due to the symmetry with pbia(). There has been discussion
about the difficulty they could introduce for the Consumer, but also a
general feeling they the portlet developer may need them. 

4. You are exactly right about the issues
involved ... they have not been resolved yet.

Rich

"Goldstein, Scott" <Scott.Goldstein@vignette.com>

05/06/2004 08:24 PM

To	<wsrp-coord@lists.oasis-open.org>
cc
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