RE: [wsrp] What faults to throw when property writes are

Yesterday, we said we would continue to use this list for spec & implementation discussion. So here goes one set of questions I would be interested to hear people's opinion on: In section 6.3.3 we say that "the producer MUST throw a fault message if the processing the interaction requires changing its persistent state" if "readOnly". We don't say what the fault MUST be. PortletStateChangeRequired I presume ...

<rt>We talked about whether to specify the fault to throw and decided to leave it up to the Producer. Interface.PortletStateChangeRequired is certainly a leading candidate.</rt> [Andre Kramer] And performBlockingInteraction declares a PortletStateChangeRequired fault...

Later, we say that "Interface.PortletStateChangeRequired" MAY be throw if the "producer implements access control that prevents Portlets from updating persistent state". Surely that should be a security (Top Level Security.) exception ;-)
<rt>Why would that be a security exception? The scenario is that a Portlet attempts to write a property that the Producer will not allow it to write. Presumably the Producer informs the Portlet of this with an exception and the Portlet decides whether it can proceed without having changed that property or whether the invocation should fail. If the decision is to fail, this statement encourages (but doesn't require) that the Interface.PortletStateChangedRequired fault message be returned. Of course, it is possible that the Portlet doesn't catch the Producer's exception and the actual fault returned is a serialization of that internal error.</rt> [Andre Kramer] The words "access control" suggest a security fault. I would hope to not expose internal errors. Also, see last fault below where you suggest Security.AccessDenied.

Also, what actual fault should be thrown for the following cases (note that not all the operations declare a throws PortletStateChangeRequired)? - a Portlet attempts to set a property in getMarkup.

<rt>Spec prohibits this. The Producer should throw an exception to the Portlet on the attempt.</rt> Should the producer throw a fault or silently discard the update or generate an error markup fragment?

<rt>The Portlet could decide to return a fault instead of markup ... probably OperationFailed. But fundamentally this would be a non-conformant Portlet</rt> [Andre Kramer] I think we should have the producer throw OperationFailed. As we specify producers, how can we talk of non-conformant portlets?

- a Consumer attempts to update a preference on a publicly offered portlet. Should the producer throw a fault or silently discard the update or generate an error markup fragment? Can we allow writes in some cases (admin level consumers)?
<rt>I think a Security.AccessDenied fault message would be appropriate. The detail message should specify that setting properties on Producer Offered Portlets is not allowed.</rt> [Andre Kramer] OK

While we are not required to align all the above, interop and testing would be improved if we tighten property update fault semantics. [Andre Kramer] An implication of the above is that PortletStateChangeRequired is likely to be used only for portletState = ReadOnly.

wsrp message