Agreed, the stated semantics is that
multiple sets of events may be sequentially distributed to any single portlet,
but concurrent distribution is prohibited. Concurrent distribution to different
portlets (same or different Producer) is allowed. If people think it would
simply state management, we could expand the nonconcurrent requirement
to all portlets sharing a groupID. Would that be valuable?
Rich
"Yossi Tamari"
<>
03/09/05 10:33 AM
To
<>
cc
Subject
RE: [wsrp] spec-2.0-draft-05:
events and blocking actions
Section 6.4.2.1 of the draft spec says: "While
the Consumer MAY invoke
handleEvent() multiple times for any one portlet while preparing to
gather markup, it MUST NOT invoke handleEvent() an additional time while
the portlet is already processing an event for the same End-User."
While it may not be stated, concurrent calls to different producers or
to the same producer for different portlets are allowed (and of course
also for the same portlet for different users).
Yossi.
-----Original Message-----
From: Subbu Allamaraju [mailto:]
Sent: Wednesday, March 09, 2005 5:10 PM
To:
Subject: Re: [wsrp] spec-2.0-draft-05: events and blocking actions
>
> There hasn't been an agreement on blocking semantics yet. I would
be
> against any semantics beyond requiring all event distribution (Note
that
> a Consumer could consider a Portlet which hasn't responded in a timely
> manner to have finished, but failed to return a response) to end
before
> starting the getMarkup step.
>
I agree that the consumer should wait for event distribution to complete
before starting getMarkup step. I've a follow-up question on the nature
of event distribution.
Can a consumer dispatch events concurrently to various producers?
If the answer "yes" or "may be", then another question
to ask is whether
a consumer can dispatch two events (or two batches of events) to a
producer for the same portlet? If the answer is "yes", then it
is going
to complicate state management for the consumer. This would also make
the outcome less predictable. It would be hard to debug for
portal/portlet developers.
Regards,
Subbu
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
