At one time, we were discussing support for a hierarchical property mechanism. I realize we haven't talked about this lately, while we're still fleshing out session/state protocol, but I thought I'd ping the group now so that this doesn't fall below the radar. In brief, hierarchical properties enable the portlet developer, portal admin, user, et al to "layer" values for a given property, based on some external criteria. A typical set of layers for a property might look like this: 1. Default: What the property will take as a value, if no one has set a value in a "higher" layer 2. Admin: The value specified by the administrator. This may be overridden by... 3. User: The value the user provides. This matches JSR 168 Preferences behavior, and certainly enhances interoperability between the two specs. Thoughts? Alan