WSRP v2 Open Issues Thirteenth face to face meeting May 2 nd – 5 th, 2006 San Francisco

Restrict NavParams types? (Mike) ● Restrict to scalars (include array of scalar types also)?

TransientProperties and getMarkup (Mike) ● Allow getMarkup to return transient properties? – Needed if we view transient properties as a remote extension of the Portlet session ● Responses suggested instead explicitly declaring getMarkup to be an idempotent operation...

MTOM and SOAP1.2 bindings? (Rich) ● Add bindings for proposed SOAP v1.2 and MTOM specs? – –

Consumer generated event UIs (Stefan) ● Use case: – portlet displays contact information about persons (name, , phone, etc) – other portlets accept such person information as event input parameter – consumer would like to generate a UI, e.g. popup that would allow the user to choose to which other portlet this information should be sent (e.g. the menu can contain things like: add to addressbook, send , call) – after selecting one item of the list the consumer would issue an event to the target portlet ● A similar paradigm is used in the windows explorer with the sendTo popup menu.

TransientProperty model (Subbu) ● Interface model like navigation Parameters or Consumer-managed (current transient properties)? ● Discussed options: – Consumer stores, manages and then supplies TPs on each relevant invocation => current spec – Producer also stores TPs and uses an update if changed algorithm to process the TPs the Consumer supplies (i.e. manages side-effects itself). – Producer informs Consumer that it also maintains TPs and the Consumer maintains 'dirty' bits to determine what to send on the next invocation. ● First has the largest message size. ● Second has the same message size as the protocol is not leveraging the fact that the Producer is also maintaining a TP store. ● Third has the smallest message size, but increases the work that the Consumer must do both when processing a new TP value and when building the message for the Portlet.

TransientProperty model (Subbu) ● Discussed options: – Consumer stores, manages and then supplies TPs on each relevant invocation => current spec – Producer also stores TPs and uses an update if changed algorithm to process the TPs the Consumer supplies (i.e. manages side-effects itself). – Producer informs Consumer that it also maintains TPs and the Consumer maintains 'dirty' bits to determine what to send on the next invocation. ● Third has an orthogonal issue regarding optimization; namely: – The protocol could support the Producer informing the Consumer that an optimization can be leveraged, but not require Consumers to take advantage of it. – The protocol could require Consumers support this optimization. – The protocol could require Consumers and Producers support this optimization.

ExtensionDescription (Rich) ● ExtensionDescription requires name & type with optional aliases, descriptions and locations. ● However, extensions could have different payloads depending on the location being extending. – For example; consider an extension, foo:bar which: ● extends ServiceDescription/RegistrationData with metadata defining whether any optional parts of the foo:bar extension are supported. ● extends one or more request messages with additional information the Consumer will supply to the Producer ● extends one or more response messages with additional information the Producer will supply the Consumer ● Should we move type and locations[] into a new structure which ExtensionDescription then includes as an array?

Portlets with Consumer stored portletState? (Stefan) ● Use case: – Portlet returns portletState in order to have this state stored on the Consumer – part of this state contains the server address where the Portlet gets the and calendar information – the Portlet is destroyed and would like to clean up the entries on the server, however, the destroy call does not provide the portletState, but only the portletHandle

wsrp:consumerSessionScopeDestroyed (Stefan) ● There are use cases where the Portlet would like to receive the current transientProperty values in this event.

transientPropertyDescriptions field (Rich) ● Add the foillowing? – An example of when this might not be appropriate is when the Portlets are related to the same Producer offered portlet handle. The context in which the Consumer is using Portlets related to the same Producer offered portletHandle will determine whether or not such Portlets will share the same values for their transientProperties.

Multiple types for an EventDescription? (Richard) ● Certain events could be generating different event types depending on portlet state, etc.

(Scoped) PropertyDescription (Richard) ● Other metadata structures have a localized description field... why not PropertyDescription & ScopedPropertyDescription? ● Why isn't the usage field a QName?

Schema types (Richard) ● We provide means to include schemas, but not URIs for simply referencing schemas

navigationParameters (Richard) ● Do Consumers have to track when a value changes or can they simply send values received in this cycle of handling a user interaction regardless of whether the value was already sent to the Portlet on an earlier invocation?

Property type (Richard) ● Other features with types carry it both in metadata and runtime... why not Property as well?

String or QName? (Richard) ● Why aren't fields like ServiceDescription.supportedFeatures QNames? ● Side issue: Do we really need to define all the values currently in the spec?

ExportDescription? (Richard) ● If we moved recommendedExportSize to a new descriptive structure, it would make it easier to add other descriptive fields in the future.

scheduledDestruction (Richard) ● Make the last sentence a conformance statement... Consumers MUST NOT send the scheduledDestruction field... ● Elsewhere too...

Http header fields (Richard) ● Should getResource supply these to the portlet? They may be needed to properly proxy the request to a back-end service. ● Should we explicitly recognize the possibility of such a Producer proxying?

Failure reasons (Richard) ● These seem more like faultcodes ● Why define QNames and have the type be string? ● Why are our faultcodes QNames?

get/set mismatch (Richard) ● SetPortletsLifetime can deal with an array, GetPortletLifetime is singular. This mismatch appears odd.

Metadata versioning (Richard) ● Would a monotonically increasing number provide a simple means to improve metadata caching? The get operations could supply this so that responses could shortcut if it is current.

Editorial (Rich) ● EventPayload: Schema allows multiple any elements, spec does not ● Could some aspect of line numbering be added to the html? [RT: Would likely require an xslt transform] ● Version the extra namespace? ● Is there a need for schemaLocation attributes? ● Make example in 3.4 explicitly the context of a CCP ● 3.6 => interactionState is as opaque as navState ● 3.8 => add handleEvents to the list of operations ● Change navigationParameters to navigationalParameters? ● New navParams are only received on URLs and responses from pbia() and he()... be explicit. ● BNF => true | 1 and false | 0

Editorial (Rich) ● MarkupParams.secureClientCommunication => can Consumers reliably set this flag??