OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [wsrp-wsia] [I#201] performBlockingInteraction/performInterac tion

In my view, the Response objects now make 2a explicit so it need not be
encoded in the operation names. We are left with the producer allowing a
concurrent (inter)action to occur in some cases (render URLs). That's why I
re-proposed perform(Inter)Action==performBlockingInteraction and

-----Original Message-----
From: Gil Tayar [mailto:Gil.Tayar@webcollage.com]
Sent: 19 December 2002 12:03
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#201]
performBlockingInteraction/performInterac tion


1. Concurrency means concurrency between portlets from the same producer. It
does not apply between producers.
2. Blocking (non-concurrency) means _two_ entirely different things:
	a. The Producer is telling the Consumer that it may return a
response that will maybe make the Consumer do an HTTP redirect, and thus the
Consumer should block returning anything to the end user until it processed
the blocking interaction response to see whether it needs to redirect or
	b. The Producer is requesting (a "kingly request") that it do
performBlockingInteraction before call the same Producer's getMarkups
because the Producer may want to do global state changes in the
performBlockingInteraction, state changes which may affect the getMarkups.
   Thus, Concurrency is an issue for the Producer, but has implications on
the Consumer - the Producer knoweth, and the Consumer executeth.

See the WSRP Primer
Section 7.5 details how the Consumer deals with requests to
performInteraction and performBlockingInteraction, and with the differences
between them. Sections 8.1 and 9.1 describes one reason (the reason in #2a
above) a Producer  may choose one over another.

I argue that moving from a "Blocking" semantics to a "Concurrency" semantics
will blur the "2a" meaning of Blocking, and thus I think we should _not_
change it. We could of course differentiate between 2a and 2b, but the Nov
F2F (unfortunately) decided against that. I would stick with the current
name/semantics - definitely at this point in time.


-----Original Message-----
From: Subbu Allamaraju [mailto:subbu@bea.com]
Sent: Wed, December 18, 2002 19:47
To: wsrp-wsia@lists.oasis-open.org
Subject: Re: [wsrp-wsia] [I#201]

A few questions (pardon me if these were discussed before):

- What does concurrency mean here? For example, does this apply to *a* 
consumer making concurrent requests to *several* producers (one request 
per producer)?

- Since concurrency is an issue primarily for the consumer, would it not 
be simpler to keep the producer unaware of this?



Eilon Reshef wrote:
> I second that. PerformBlockingX is a misnomer, since the operation 
> itself doesn't block - rather we expect that the Consumer would block, 
> but that's also not true as it may request portlets from other Producers 
> in parallel. Hence, blocking doesn't seem like the right idiom in our 
> concurrent environment.
> I think performInteraction and performConcurrentInteraction make much 
> more sense (though I do think that interaction is better than action, as 
> action implies some high-level (framework-oriented) concept which we 
> don't necessarily provide or promote explicitly).
>     -----Original Message-----
>     *From:* Gil Tayar [mailto:Gil.Tayar@webcollage.com]
>     *Sent:* Wednesday, December 18, 2002 4:04 AM
>     *To:* wsrp-wsia@lists.oasis-open.org
>     *Subject:* [wsrp-wsia] [I#201]
>     performBlockingInteraction/performInteraction
>     Issue: 201
>     Status: Active
>     Topic: interface
>     Class: Minor_Technical
>     Raised by: Andre Kramer
>     Title: performBlockingInteraction/performInteraction
>     Date Added: 18-Dec-2002
>     Document Section:   v0.85/5.3
>     Description:
>     performBlockingInteraction has proved very cumbersome to communicate
>     and we very much want to encourage people to use it over
>     performInteraction. And it still does not mirror JSR168's
>     Resolution:
>     "Review decision of last f2f based on pedantic feedback:-
>     performAction and
>     performConcurrentAction. Return structures
>     BlockingInteractionResponse, InteractionResponse could become
>     InteractionResponse (blocking inter-action) and ActionResponse
>     (concurrent and blocking actions)."

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC