[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp-wsia] WSRP / JSR 168 Alignment
Dear WSRP / WSIA TC Members, please find attached a summary of our recent discussions with the JSR 168 spec leads. Alejandro, Rich and Carsten will give an overview of the recent discussions in today's TC call. Best regards, Thomas ---------------------- Forwarded by Thomas Schaeck/Germany/IBM on 10/24/2002 01:42 PM --------------------------- Stefan Hepper 10/24/2002 11:15 AM To: Thomas Schaeck/Germany/IBM@IBMDE, Carsten Leue/Germany/IBM, Rich Thompson/Watson/IBM cc: Alejandro Abdelnur <alejandro.abdelnur@sun.com>, JSR-168-EG@JCP.ORG From: Stefan Hepper/Germany/IBM@IBMDE Subject: recapping discussions with WSRP editors Dear WSRP TC and JSR168 EG, [This email is being sent to the WSRP editors and JSR168 EG aliases.] Following there is the list of areas we found we have to work to ensure a proper alignment between JSR168 and WSRP specifications. This email is correction/addition/clarification to the previous email we've sent to Thomas a while ago, the one that has been forwarded to both groups. Please let us know of any corrections, additions and questions you may have. Regards. Alejandro / Stefan JSR168 specification co-leads [IINA acronym: Impact If there is Not Alignment ] 1------------------------------------------------------------------- Action definition differs between JSR168 and WSRP. WSRP defines actions as the event where all state changes happen. JSR168 defines actions as the event where state changes that affect other portlet changes happen. When JSR168 EG decided to get rid of non-blocking action from the API one of the key arguments was that it could still be possible to model non-blocking actions by using getMarkup. This non-blocking behavior can and should only be used if the portlet is not modifying a state that may affect other portlets, otherwise the overall behavior may not be deterministic. This means a different programming model for WSRP and JSR portlets. Specifically, JSR168 allows changing properties in getMarkup. WSRP does not allow changing properties during the getMarkup. IINA: Medium/High. JSR168 based producers would have to use producer managed properties. Providing that WSRP remove this restriction in the case of producer managed properties. Or, as part of the WSRP programming guidelines it would have to have extra requirements for JSR168 portlet developers. **After Discussion between JSR168 leads and WSRP editors: Discussion drifted a little from initial issue. WSRP editors consider it's a requirement for the entity to be aware of the fact a copy on write happens. WSRP editors consider a binary copy of properties upon clone is not enough. Making the entity aware that is being copied/cloned it would allow the entity to clone its backend state (other state than properties). Alejandro does not see why backend information (external to the portal) should be aware of the portlet entity is using it (i.e.: ERP systems, financial systems). Portlets are just a presentation layer among many, backend should not be aware of that. JSR168 does not provide any mechanism to notify the portlet an entity cloningt happens. JSR168 portlets receive a properties set with each request, they do not care if the properties set is the default one or a customized one. The portlet container, in a transparent maner, makes a copy upon customization and provides the new copy from that point forward. Early on JSR168 EG has decided entity lifecycle would be out of scope for v1.0. WSRP editors propose portlet containers to expose the entityID to the portlets. This would allow a portlet, on an invocation, to check if it's entityID has changed (it would store the last know value as a property). If the entityID has changed the portlet could trigger the backend copy/clone behavior and update the entityID stored in the properties. if an JSR168 portlet wants to ensure a private entity is used by it could trigger a entity clone by changing a property value. Solving the copy-on-write issue would therefore require: 1. Introduce Mike's proposal for performInteraction in WSRP 2. Introduce notion of portlet entity identity in JSR Not resolved initial issues: modification of state (specifically properties) in the getMarkup call. This requires further discussion in the WSRP group. State: Open for more discussion 2-------------------------------------------------------------------- JSR168 allows setting properties not defined in the portlet (entity type) definition It is not clear if WSRP allows setting properties not defined in the entity type metadata. IINA: Low/Medium. JSR168 based producers would have to use producer managed properties. **After Discussion between JSR168 leads and WSRP editors: WSRP does not forbid this for producer managed properties neither consumer manage properties. WSRP would clarify it is possible to do so. State: If TC/EG agrees, closed 3-------------------------------------------------------------------- JSR168 property types are of String or String[]. Types are interchangeable (a String value can be replaced with a String[] value) WSRP allows type <any> for properties IINA: None. Entities offered by JSR168 based producers would only use String and String[] values. A JSR168 based producer would not use other types. **After Discussion between JSR168 leads and WSRP editors: This is not an issues as JSR168 is using a subset of WSRP. As the entity defines the properties types, JSR168 portlets would restrict their property types to String, String[]. State: If TC/EG agrees, closed 4-------------------------------------------------------------------- JSR168 properties definition can define a property as non-modifiable (by the end user) WSRP does not define a non-modifiable attribute for properties. IINA: Low/Medium. For producer managed properties none, this functionality is handled completely by the producer. For consumer manage properties, an extension would have to used. **After Discussion between JSR168 leads and WSRP editors: WSRP properties definition (PropertiesDescription data structure) has an extension mechanism that could be used to express the non-modifiability of a property. In addition, WSRP editors suggest producers should not expose to the consumer properties that are not meant to be modified by the consumer. State: If TC/EG agrees, closed 5-------------------------------------------------------------------- JSR168 does not define properties metadata such as value-type, is-value-required, min-value, max-value, valid-values. JSR168 only defines name/value/modifiable (String/String|String[]/boolean). IINA: None. JSR168 producer implementations could define extensions to expose WSRP properties metadata **After Discussion between JSR168 leads and WSRP editors: No issue here. JSR Portlets can map XML fragments into preference values State: If TC/EG agrees, closed 6-------------------------------------------------------------------- JSR168 defines the concept of windowID to uniquely identify an occurrence of a portlet in a portal page. The windowID is used by the JSR168 producer to manage the session scope for portlets. The windowID must not change during the duration of a session. INNA: If the WSRP 'refHandle' can be used for this purpose this is a non-issue (The copy-on-write or alternate-solution may have some consequences on this). Otherwise: Medium/High. Consumers wanting to interact with JSR168 based producers would have to implement the extension the JSR168 producer defines for that. This would be problematic as different JSR168 based producers could define this extension in a different way. **After Discussion between JSR168 leads and WSRP editors: Apparently this is not an issue. The first call a user makes the entityHandle will be passed and the producers has to create the refHandle for it. When creating a refHandle, a producer could encode in it a windowID to be used in subsequent calls during the same session. State: If TC/EG agrees, closed 7-------------------------------------------------------------------- JSR168 wants to use the same CSS styles but with a more generic prefix such as 'portlet-' or 'fragment-' WSRP is defining 'wsia-' as prefix for the CSS sytles. IINA: Medium/High. Common look and feel would not be achieved unless the consumer uses both styles. **After Discussion between JSR168 leads and WSRP editors: It shouldn't be a problem agreeing in a common prefix, the idea would be to use 'portlet-' until/unless a better name is found. State: If TC/EG agrees, closed. 8-------------------------------------------------------------------- JSR168 portal/portlet-container extensions are expressed as String name-value pairs (where a given name may have several occurrences, a la HTTP headers) WSRP allows type <any> for extensions IINA: Medium/High. JSR168 producers and portlets will have to rely on vendor provided types to access this extensions. Relying on vendor provided types will most likely create runtime exceptions because missing class or cast problems. It would impact JSR168 producers and portlets portability. Question: Is the intention of WSRP to use <any> for future features (post v1.0) and to state that extensions must be expressed as string elements in v1.0? **After Discussion between JSR168 leads and WSRP editors: WSRP editors want to keep extensions as <any> elements. It was discussed that JSR168 provider could handle this elements as Strings containing the fragment of the <any> element. The <any> element would have to specify the schema inline, to allow a proper parsing and interpretation. If the type of the <any> element is of String type, the JSR168 could process it and offer the parsed value to the portlet. State: Open for more discussion. 9-------------------------------------------------------------------- JSR168 needs the list of allowed portlet-modes and window-states on processInteraction and getMarkup calls to allow the producer to restrict to allowed values portlet-mode and window-states changes and portletURL creation. WSRP does not provide this information IINA: Medium/High. Consumers wanting to interact with JSR168 based producers would have to implement the extension the JSR168 producer defines for that. This would be problematic as different JSR168 based producers could define this extension in a different way. **After Discussion between JSR168 leads and WSRP editors: WSRP editors state that validating the portlet-mode and window-state set by the portlet in a URL at the time this is set has not much value because at the time the user clicks the link the permissions may have changed. JSR168 EG considers portal/portlet container should use current knowledge when creating PortletURLs to avoid creating URLs with invalid portlet-modes and window-states. The use case of permissions changing between the time a URL was created and when it's clicked is considered rare. JSR168 requires the container to throw an exception if a portlet attempts to change to a portlet-mode or window-state during the processAction call and the portlet/user is not allowed to change. WSRP does not provide a mechanism to enable this. Furthermore, WSRP does not require the consumer to process/accept the change. JSR168 leads to provide an use case where not enforcing the change and not throwing the exception would cause problems. [Alejandro's afterthought] JSR168 had, for non-blocking actions, the current behavior WSRP has now for change of portlet-mode and window- state when doing a performInteraction. But for blocking actions if a portlet requested a change and it was valid, the portal must do it. This different behavior also was eliminated with the removal of non- blocking actions. At that time also JSR168 EG discussed and agreed that change request must be honored because if not a portlet could not be ensured it would change to a new portlet-mode or window-state. The use case for this being a must was a performInteraction processing an EDIT, updating some properties and asking the portlet to go back to VIEW mode. [outcome of the last JSR conf call about this topic]: The JSR168 EG thinks it does make sense to give the portlet feedback about the window states and portlet modes the current user is allowed to access. For URLs that are created it is accepted to loosen the requirement that the portlet must be called in the state/mode encoded in the URL. For URLs the portlet container need to act on the best knowledge available at the time the portlet creates the URL, but there are no guarantees. For setting a portlet mode or window state in the blocking action the EG does not see why the container can not provide immediate feedback if the mode change is allowed or not. The portlet must rely on the bahavior that a successfully set portlet mode or window state in the action will be the mode/state that the portlet will be in for the following render call. State: Open for more discussion. Issue with setting portlet mode and window state in action still not solved. 10------------------------------------------------------------------- JSR168 defines a simple expiration cache on a per session basis. WSRP is considering a more complex validating cache mechanism. IINA: None. JSR168 producers could expose the WSRP caching as an extension. NOTE: JSR168 EG is waiting for WSRP resolution on caching to see if a more complex mechanism could be supported in v1.0. **After Discussion between JSR168 leads and WSRP editors: This is not an issue as JSR168 provides a special case of what WSRP is considering. State: JSR168 EG will evaluate WSRP proposal. JSR168 community draft would state this a more complex caching mechanism may appear in the final spec. 11------------------------------------------------------------------- JSR168 can not model WSRP entity creation using copy-on-write without exposing the copy-on-write behavior to the portlet developers. IINA: High. It would seriously affect interoperability between JSR168 and WSRP. **After Discussion between JSR168 leads and WSRP editors: Current WSRP dicussion on this could address this issue. See also issue no. 1 State: Open until WSRP concludes this dicussion. 12------------------------------------------------------------------- Window States and Portlet Modes constants differ between JSR168 and WSRP. WSRP: VIEW_NORMAL, VIEW_MINIMIZED, VIEW_MAXIMIZED, VIEW_MODE, EDIT_MODE, HELP_MODE. JSR168: NORMAL, MINIMIZED, MAXIMIZED, VIEW, EDIT, HELP IINA: Low. JSR168 producers would have to map the WSRP window state names to the JSR168 window state names on each performInteraction/ getMarkup. **After Discussion between JSR168 leads and WSRP editors: This is not a big issue, a simple mapping could be done if there is not aligment. It was agreed that it would be nice to have common names here. Also it seems that current WSRP constants names are redundant. State: Will raise issue in WSRP proposing JSR168 style and drop the redundant VIEW_ and _MODE. 13------------------------------------------------------------------- JSR168 does not provide localization support for portlet type metadata (portlet name, init parameters, properties). IINA: None. JSR168 producer implementations could define extensions to expose WSRP properties metadata. **After Discussion between JSR168 leads and WSRP editors: JSR168 will define an xml:lang attribute for the deployment descriptor elements that require localization. From the discussion it seems a JSR168 producer could use this info for WSRP purposes. WSRP should use the approach for WSRP titles and descriptions. State: If TC/EG agrees, closed [outcome of the last JSR conf call about this topic]: JSR168 EG agreed to introduce the xml:lang attribute. 14------------------------------------------------------------------- JSR168 defines User Information as String name-value pairs with not structure. WSRP defines a structured element for User Information. IINA: Low. JSR168 producer will have to flatten the WSRP User Information structure into String name-value pairs. **After Discussion between JSR168 leads and WSRP editors: WSRP editors suggest JSR168 should make a recommendation to use P3P-names/WSRP-names styles. As JSR168 defines a mapping mechanism for this is not really an interoperability issue. It would just help plug&play. JSR Leads will propose in the EG to make an appendix with a recommendation to portlet programmers to use P3P user attribute names for interoperability. State: If TC/EG agrees, closed 15------------------------------------------------------------------- JSR168 allows portlets to access uploaded data from both performInteraction and getMarkup. If the request was made with an action URL uploaded data is available in the performInteraction call. If the request was made with a render URL uploaded data is available in the getMarkup call. In WSRP uploaded data is only available in performInteraction. **After Discussion between JSR168 leads and WSRP editors: JSR action and render phases do not need to be mapped to WSRP performAction and getMarkup calls. For the JSR non-blocking actions that are created with a special API call (PortletResponse.createRenderURL) the portlet container can tag this URL and return it as WSRP action URL. When the container receives the WSRP performAction call the container calls portlet.render() returns the WSRP params as response to the action and caches the markup produced by the portlet. When the container receives the getMarkup call from the WSRP consumer it returns the cached portlet response. State: If proposed solution works for all cases, closed. ==================================================================== NEW ISUE NOT DISCUSSED BETWEEN WSRP editors and JSR leads: 16------------------------------------------------------------------- JSR 168 portlets must define valid modes per markupType. The WSRP EntityDescription structure (WSRP0.8 7.1.1) does not provide for this information. IINA: Medium/High A consumer portal will not be able to correctly generate EDIT/HELP links on the portlet decorations for different markups (e.g. a portlet may support EDIT for HTML, but not for WML). State: not yet discussed ---------------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC