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:]
Sent: Wednesday, August 13, 2003 9:47 
  PM
To: 
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