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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-coord message

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


Subject: RE: [wsrp-coord] Use properties to expose transient state?


Hi Rich,
 
I don't see how we can use the current model for this, even if we add State Lifetime. The current setPortletProperties method is in the Portlet Management Interface, while we clearly need to be in the Markup Interface. Also the signatures that are needed in both cases are quite different, and so is the expected behavior of the producer.
 
If you are only suggesting to reuse getPortletPropertyDescription for metadata retrieval, I still see some issues, like the fact that I think state properties must expose some extra metadata, for example ReadOnly/WriteOnly/ReadWrite. My design approach would be to first design a different method and structures, and then see if we can naturally unify the two, without creating situation where a consumer/producer that supports one must support the other (at least on some level).
 
    Yossi..
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Wednesday, August 13, 2003 9:47 PM
To: wsrp-coord@lists.oasis-open.org
Subject: [wsrp-coord] Use properties to expose transient state?


Q: Do we want to expand the current property concept to include published transient state?

[RDT] I think this would be the simplest model for developers. State is all stored in properties, what varies is the lifetime of that state. What we have now is "persistent state" and therefore survives application cycles, etc. Transient state should have a lifetime similar to that of a session.

A side-effect of the decision to support Consumer generated UIs for customizing persistent state is the need to distinguish between persistent and transient properties. The subcommittee last working on this proposed organizing the properties into models, each of which could then indicate the lifetime of the model. Comments? Other proposals?

Rich Thompson


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