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] (Required feature?) Transient property follow up


I'm not convinced that we should make this a required feature.
The shared session context provided here is really a loaded gun.
I'm afraid developers will use this not only for coordination purposes but
also for private data collection purposes.
Our experience is exactly this behavior. The biggest can they can get, they
stuff it in, because it's convenient.
And we had various talks about whether we enable a "better" world and try
to teach, or whether we take some current practices as a given and don't
support them (well), e.g. the famous method=GET discussion was one example
here.

We really need to be carefull in order to allow Consumers to remain
scalable. Experience shows that blowing up the session size is one of the
main scaling prohibitors.
I think it's a big difference between storing only the wsrp session ID in
the Consumer's session and a large amount of portlet data.
Consumers should be free to reduce the amount of resources they want to
offer here.

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 
             10/24/05 05:24 PM         wsrp <wsrp@lists.oasis-open.org>    
                                                                        cc 
                                                                           
                                                                   Subject 
                                       Re: [wsrp] (Required feature?)      
                                       Transient property follow up        
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




I agree with the language proposed below. Of course, we need to read it
in the context of the spec :)

On the naming issue, I agree with Mike's concerns on extensibility in
future versions of the sepc as well vendors. The term "transient" is
more extensible.

Subbu

Rich Thompson wrote:
>
> But the equivalence would only hold if the scope is wsrp:portletSession.
> Since we are defining a scope related to the End-User's interactions
> with the Consumer, I would think any requirements should relate to those
> interactions rather than the interactions of the Consumer with the
> portlet. Perhaps something like:
> The Consumer MUST initiate the wsrp:consumerSession scope whenever a new
> set of interactions with an End-User are initiated and MUST NOT
> terminate this scope until either those interactions cease or resources
> related to the End-User's interactions are released due to inactivity.
> The Consumer MUST NOT automatically null out all settings of transient
> property values within the wsrp:consumerSession scope.
>
> I think this pair ends up making the feature required of Consumers,
> provides a distinct definition of the scope and makes transient
> properties usable by portlet developers.
>
> Any thoughts on renaming this feature to "Session Properties"?
>
> Rich
>
>
> *Michael Freedman <michael.freedman@oracle.com>*
>
> 10/19/05 03:33 PM
>
>
> To
>            Rich Thompson/Watson/IBM@IBMUS
> cc
>            wsrp <wsrp@lists.oasis-open.org>
> Subject
>            Re: [wsrp] (Required feature?) Transient property follow up
>
>
>
>
>
>
>
>
> For the portlet that is deciding to use the session Transient property
> as an alternaitve to storing state it might otherwise store in a
> portletSession wouldn't there be an interest in whether or not there is
> a relationship in how the consumer manages these two?  My point in
> making them equivalent is that portletSession becomes opaque or private
> session data while consumerSessionScoped transient property become
> public session data.
>   -Mike-
>
> Rich Thompson wrote:
>
> Your two questions are sufficiently different that I suggest splitting
> the discussion into two threads.
>
> Relative to making Transient Properties a required feature. I would
> agree that for this feature to be truly useful, portlet developers need
> to have it be dependable. Any arguments against making it required?
>
> If we do make this a required feature, I don't think it is the lifetime
> that needs to be clarified. Rather, it is prohibiting a claim for
> support that simply has a Consumer component which always sets property
> values to null.
>
> On a similar note, I have been thinking lately that a better name for
> these would be "Session Properties". Transient Properties is a bit too
> ambiguous and tends to raise the questions about why both these and
> Navigation Parameters. No matter what additional scopes are defined,
> what we have defined is semantically an extension of the Portlet's
session.
>
> Rich
>
> *Michael Freedman **_<michael.freedman@oracle.com>_*
> <mailto:michael.freedman@oracle.com>
>
> 10/18/05 03:21 PM
>
>
> To
>            wsrp _<wsrp@lists.oasis-open.org>_ <
mailto:wsrp@lists.oasis-open.org>
> cc
>
> Subject
>            [wsrp] Transient property follow up
>
>
>
>
>
>
>
>
>
>
> A couple of questions/issues I came up with post F2F on Transient
> properties:
> 1.        Should the meta data that describes transient properties be
> improved to support a notion of aliasing?
> Is there value in distinguishing between the name the portlet receives
> the transient property as and the set of [coordination] names that
> identify this property to the consumer?  The use case is two [sets of]
> portlets that are developed independently each with their own
> namespace/vocabulary for properties sometime afterwards understanding
> that coordination could also occur between them because the property
> [semantics] are the same.  Current model requires the one/both to change
> its implementation with potential backwards compatibility impacts.  We
> could however offer another field in the TransientPropertyDescription
> that is an array of aliases which identify other identities of the same
> property.  Should we add this to our 2.0 design?
>
> 2.        By defining a specific/known duration for consumerSession
> scope can we make this a required feature in 2.0?
> My understanding from our F2F discussions is that producers couldn't
> rely on transient properties to hold internal state because though we
> required support for this feature we said it was valid for the consumer
> to claim support by merely always sending/representing a null value
> [i.e. value always out of scope].  I think this is a severly restricts
> the value of transient properties and makes them more akin to
> NavigationalParameters.  Since all we are defining is the
> consumerSession Scope and that we though unstated this scope is
> implied/must exist in WSRP 1.0 to support managing portletSessions can
> we stengthen our proposal by requiring that a transientProperty of
> consumerSessionScope must be maintained for the exact amount of time
> that the consumer maintains the portlet's session assuming that portlet
> session has an infinite lifetime from the perspective of the producer?
>  [I.e. portlet session timeouts aren't a factor in this].  By equating
> this transientProperty scope to the same scope that the consumer manages
> portletSessions on we create an equivalence between the management of
> public session state and opaque session state meaning the portlet can
> now depend on the public state.
>   -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
> --------------------------------------------------------------------- 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]