Michael, Your inclination towards the web approach is largely based on scalability reasons - i.e. try to reduce the amount of information the Consumer has to store per all entities per all users. To that effect, let me try and continue to search for reasons why a Consumer will _have_ to have information per-entity-per-user. In the discussion in the joint interfaces meeting yesterday, I suggested that the Consumer would have to store (per-entity-per-user) whether to call performAction or getFragment. You, rightly so, told me that you never liked the distinction so that this is (not yet) a valid argument. To tell you the truth, I'm not sure *I* like the distinction between performAction and getFragment. It may be that we will have *only* performAction, where the action should be _exactly_ the URL state you mentioned in your point (a) below. Well, in this case, if the consumer has multiple portlets on the page, it _must_ store the last action of all of them, and this _must_ be per-user. To contrast with the web approach, in the simple Web application, the browser stores the application's state in the address bar per-user. In the WSRP/WSIA scenario, the Consumer must also store that information, per-portlet! This is the only way to allow stateless portlets. Am I missing something? Gil