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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

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


Subject: Re: [wsrp] Few clarifications on stateChange flag and consumer-managedstate


Rich,

IMHO adding the explicit clarification along the line that you provided

".. the portlet MAY change its enduring state. A PortletContext is 
returned *only* if there was such a change *AND* it is persisted on the 
Consumer."

would be quite helpful for a spec implementor/reader particularly that 
state mgm is crucial aspect of the spec.

Regards,
Wesley

Rich Thompson wrote:

>
> Sure, modifyRegistration (7.3) returns a RegistrationState (5.1.24) 
> which does not include a registrationHandle since the Producer is not 
> allowed to change the handle when processing this operation. This was 
> also true in v1, though the section numbers were different.
>
> I understand that your only concern is the discussion of 'readWrite'. 
> My point was that 'cloneBeforeWrite' is the only place where the 
> semantics allow a clone to be returned. We could state the negative 
> for both of the other defined values for the portletStateChange flag, 
> but applying such an approach across the spec would become onerous. On 
> the other hand, if the consensus is that additional statements would 
> provide clarity, then we should add them.
>
> Rich
>
>
> *Subbu Allamaraju <subbu@bea.com>*
>
> 03/16/06 10:42 AM
>
> 	
> To
> 	Rich Thompson/Watson/IBM@IBMUS
> cc
> 	OASIS WSRP TC <wsrp@lists.oasis-open.org>
> Subject
> 	Re: [wsrp] Few clarifications on stateChange flag and 
> consumer-managed state
>
>
>
> 	
>
>
>
>
>
> Rich Thompson wrote:
> >
> > The 2nd is not needed as the Producer CAN NOT (stronger than MUST NOT!)
> > return a registrationHandle from modifyRegistration.
>
> Could you me to the section that has this statement? The producer has to
> return the current registrationHandle since it is required in the
> schema. My expectation is that the producer returns an updated
> registrationState along with the current registrationHandle.
>
> >
> > The only setting of portletStateChange that allows for cloning is
> > 'cloneBeforeWrite' (section 6.4.3). The PortletContext.portletState
> > description explicitly connects the value supplied to the value in the
> > required portletHandle field. Personally this structurally states the
> > equivalent of the suggested conformance statement. However, if others
> > think an additional conformance statement does make sense, I would
> > suggest adding it to 6.4.3 (where the semantics of the
> > portletStateChange flag are discussed).
>
> Just want to make sure we are talking about the same thing. I agree that
> the spec is clear on cloneBoforeWrite. The proposal is only for readWrite.
>
> Subbu
>
>
> > *Subbu Allamaraju <subbu@bea.com>*
> >
> > 03/16/06 09:38 AM
> >
> >                  
> > To
> >                  Rich Thompson/Watson/IBM@IBMUS
> > cc
> >                  OASIS WSRP TC <wsrp@lists.oasis-open.org>
> > Subject
> >                  Re: [wsrp] Few clarifications on stateChange flag 
> and consumer-managed
> > state
> >
> >
> >                  
> >
> >
> >
> >
> >
> > Rich,
> >
> > I agree with that interpretation. But the spec does not specify that the
> >  producer MUST NOT return a new portletHandle when readRead is supplied
> > by the consumer.
> >
> > In the case of registration, the producer MUST NOT return new
> > registrationHandle in response to a modifyRegistration request.
> >
> > I think both these are required since consumers may be using the handles
> > as keys in databases.
> >
> > Subbu
> >
> > Rich Thompson wrote:
> >  >
> >  > PortletHandle is a required field in PortletContext and the semantics
> >  > are that any portletState included in the PortletContext is 
> relative to
> >  > the portletHandle (Consumer MUST return it on future use of the
> >  > portletHandle).
> >  >
> >  > I think this eliminates the need for the conformance statement as 
> it is
> >  > already encapsulated in the structure of the message.
> >  >
> >  > Rich
> >  >
> >  >
> >  > *Subbu Allamaraju <subbu@bea.com>*
> >  >
> >  > 03/16/06 08:34 AM
> >  >
> >  >                  
> >  > To
> >  >                  OASIS WSRP TC <wsrp@lists.oasis-open.org>
> >  > cc
> >  >                  
> >  > Subject
> >  >                  [wsrp] Few clarifications on stateChange flag and
> > consumer-managed state
> >  >
> >  >
> >  >                  
> >  >
> >  >
> >  >
> >  >
> >  >
> >  > Mike Caffyn and I had some discussions on the correct 
> interpretation of
> >  > the stateChange flag when the consumer is managing the state (via
> >  > portletState).
> >  >
> >  > Here are the possibilities:
> >  >
> >  > Consumer: Sends a readOnly flag and portletContext
> >  > Producer: Can either throw a fault if changes are required, or 
> process
> >  > normally but must not return a portletContext.
> >  >
> >  > Consumer: Sends a cloneBeforeWrite flag and portletContext
> >  > Producer: Returns a portletContext with a new portletHandle and 
> possibly
> >  > new portletState
> >  >
> >  > Consumer: Sends a readWrite flag and portletContext
> >  > Producer: Returns a portletContext with the *same* portletHandle and
> >  > possibly *different* portletState.
> >  >
> >  > I did a quick search in the Conformance spreadsheet and could not 
> find a
> >  >  statement about whether "the producer MUST return the same
> >  > portletHandle along with the same/modified portletState when consumer
> >  > supplies readWrite".
> >  >
> >  > If we have overlooked something, let me know.
> >  >
> >  > I think the same question applies to modifyRegistration.
> >  >
> >  > Regards,
> >  > Subbu
> >  >
> >  > ---------------------------------------------------------------------
> >  > To unsubscribe from this mail list, you must leave the OASIS TC that
> >  > generates this mail.  You may a link to this group and all your TCs
> > in OASIS
> >  > at:
> >  > 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >  >
> >  >
> >  > 
> --------------------------------------------------------------------- To
> >  > unsubscribe from this mail list, you must leave the OASIS TC that
> >  > generates this mail. You may a link to this group and all your TCs in
> >  > OASIS at:
> >  > 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  You may a link to this group and all your TCs 
> in OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> > 
> --------------------------------------------------------------------- To
> > unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail. You may a link to this group and all your TCs in
> > OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
> --------------------------------------------------------------------- 
> To unsubscribe from this mail list, you must leave the OASIS TC that 
> generates this mail. You may a link to this group and all your TCs in 
> OASIS at: 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 




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