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] Session scoped transient properties.


Yes, agree.
I think it is important to us to keep the phases seperate and have the
idempotent operations. Otherwise while keep them distinct?

I think we discourage (at least the JSR168 does) to write shared session
state in render - and this for good reasons we all seem to agree on.
As Mike said this was allowed because of "backward compatibility" to old
web applications which didn't have such seperation.
But we should not forget that the biggest difference between WSRP/portal
model and the web model is the aggregation and coordination. Now once we
have aggregation, having idempotent operations is crucial to a clean UI
model, i.e. GM and GR are the view part of the overall pattern.

Now with transient properties we even extend the aggregation/coordination
model. Now portlets not knowing each other and not written against each
other (one could expect JSR168 portlets in the same application have a good
knowledge of each other and thus know what they share via a session) work
together in a coordinated manner. This add another dimension and complexity
here and I think relexing the idempotency requirements would make things
worse and UIs akward.
I think it's ok to have this new feature being more restrictive and
enorcing a better UI design/behavior.

Mit freundlichen Gruessen / best regards,

        Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Team Lead & Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com


                                                                           
             Subbu Allamaraju                                              
             <subbu@bea.com>                                               
                                                                        To 
             03/22/06 11:11 PM         Michael Freedman                    
                                       <michael.freedman@oracle.com>       
                                                                        cc 
                                       wsrp <wsrp@lists.oasis-open.org>    
                                                                   Subject 
                                       Re: [wsrp] Session scoped transient 
                                       properties.                         
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




I agree with Rich's point on idempotency. From the web developer's point
of view, you are right that this requirement forces some constraints,
and developers may find this awkward when you try to explain why it is a
bad idea to change state during a getMarkup. But from the protocol's
point of view, if we relax the idempotency requirement, there will be
some negative consequences. There will be less guarantee for such
session scoped transient properties to work. Portlets may think that
they are able to make state changes, but those may remain local, or may
get lost on a subsequent call. There is another point we need to
consider. If we allow request scoped properties in future, it would be
hard to match it with getMarkup.

Subbu

Michael Freedman wrote:
> I agree completely.  The issue comes down to whether our protocol
> enforces the convention or merely identifies it as best practice.  If we
> allow the return of transientProperties I would expect us to provide
> clarifying terms that reference a best practice statement (or some such
> thing).  As for the unexpected behavior:  Noted that the problem is
> worse, but in many portlet environments changing session state can
> impact other portlets in that producer and hence portlet developers have
> to recognize/avoid getting themselves into a fix.  Which brings us back
> to the question then of why should we allow this in the first place?  I
> believe you answered that in your message when you described that in the
> existing web world containers pass this issue to component developers.
> The reality is these are some of the same component developers wanting
> to provide portlets.  Many come from a perspective/expectation that they
> should be able to adapt their existing component code quickly and easily
> into the portlet environment (some in fact don't even know they are
> running as portlets as that adaption is done underneath them by the MVC
> system/bridge technology).  Right now our design forces these vendors to
> rewrite their existing work which delays their migration.
>     -Mike-
>
> Rich Thompson wrote:
>>
>> This likely revolves around how one views idempotency and the WSRP
>> protocol.
>>
>> It has been frequently argued that there is a straight-forward mapping
>> of the HTTP verbs to WSRP operations and, in particular, that
>> getMarkup and getResource are idempotent operations. Whether one
>> agrees with that assertion or not, there is the next level of issue in
>> that many sites relax idempotency to only include transactional items
>> and not 'trivial' things (such as hit counters) or the caching of
>> items in a user session. It is often these use cases that drive
>> container decisions to not enforce the idempotent requirements of
>> certain interactions, but rather to pass the issue on to component
>> developers. At this philosophical level, a key question is whether
>> adding the ability to return transientProperties with response to GM
>> and GR wouldn't be a declaration that these aren't really idempotent
>> interactions. (The "container" is allowing non-idempotent behavior
>> without knowledge as to whether it will be used in a "transaction"
>> manner ... and components can not determine this either.)
>>
>> On a practical level, it seems like adding this feature would cause
>> page refreshes to exhibit unexpected behavior. Consider when portlet A
>> generates its markup and then portlet B updates a transient property
>> both receive. A page refresh would cause a change in the markup from
>> portlet A which would likely be unexpected in many cases and would
>> definitely exhibit that the page wasn't conforming to idempotent
>> requirements. I'm not sure this is entirely a bad thing, but it
>> shouldn't be taken lightly either.
>>
>> Rich
>>
>>
>> *Michael Freedman <michael.freedman@oracle.com>*
>>
>> 03/21/06 04:28 PM
>>
>>
>> To
>>           wsrp <wsrp@lists.oasis-open.org>
>> cc
>>
>> Subject
>>           [wsrp] Session scoped transient properties.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Currently we don't allow getMarkup and getResource to return
>> transientPropertyUpdates; only performBlockingInteraction and
>> handleEvents can.  Should we remove this restriction?
>>
>> Currently, we don't allow navigational state, mode, window state changes
>> from getMarkup/getResource because we can't ensure the consumer can
>> implement reasonable semantics.  To a lesser extent we disallow this
>> because our model discourages state changes during render.  However,
>> because we can't control internal producer session state this is a
>> convention not something that can be fully enforced.
>>
>> I believe setting transient session properties at GM/GR time can be
>> semantically defined -- its no different then doing such a thing locally
>> in a concurrent world.  I.e. the consumer honors such sets immediately
>> [as with handleEvents].  So, though we would continue to want to
>> discourage transient property state changes should we prevent it merely
>> on the grounds that its not our preferred model?
>>
>> What we lose by having this restriction are degrees of freedom in how
>> environments built on top of wsrp that ease portlet development will
>> expose this concept.  One reasonable model [that JSR 286 is currently
>> advocating] is to not distinguish within portlet code between transient
>> session properties and producer session properties.  From a code
>> perspective there are just session properties.  The code reads/writes
>> these values without explicit knowledge as to whether the value is
>> shared with the consumer.  That detail is described in
>> configuration/metadata. The JSR 286 container is responsible for moving
>> the appropriate values to/from the session from/to the consumer.  Like
>> wsrp, the jsr discourages session state changes during
>> render/getresource.  Also like wsrp it doesn't prevent such changes.
>> With the current restriction the JSR is faced with either tightening its
>> requirements to throw an exception if any session writes are attempted,
>> allowing the local writes but throw an exception for those session
>> properties that are shared [transient], or merely updating the values
>> locally but not returning such state to the consumer [meaning these
>> updates will be lost on the next request as the transient properties are
>> pushed again with the old values].  All three of these are behaviors
>> will be foreign to java [web app] developers.
>>   -Mike-
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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]