[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp-wsia] JSR168 & WSRP alignment
Best regards, Thomas ---------------------- Forwarded by Thomas Schaeck/Germany/IBM on 10/17/2002 05:11 PM --------------------------- Alejandro Abdelnur <alejandro.abdelnur@sun.com> on 10/03/2002 04:44:47 AM To: Thomas Schaeck/Germany/IBM@IBMDE, Stefan Hepper/Germany/IBM@IBMDE, Alejandro Abdelnur <alejandro.abdelnur@sun.com> cc: Subject: JSR168 & WSRP alignment Dear Thomas, The JSR168 expert group is closely following the WSRP development with great interest to ensure interoperability between the two technologies. We are contacting you, in your role of OASIS WSRP chairman, to share with the WSRP TC the current status of JSR168 related to WSRP. Weve managed to ensure that most of the WSRP functionality is aligned with JSR168 functionality. However, there are some areas where we could not accommodate our functionality to the WSRP functionality or the other way around. These differences may have a direct impact on the degree of interoperability between WSRP and JSR168 technologies. Because of this, JSR168 expert group has considered relevant to bring these issues to the attention of the WSRP TC. *Properties changes: WSRP allows modification of property values in the performInteraction call only. JSR168 allows portlets to modify properties within the performInteraction and getMarkup calls. The JSR168 expert group considers that allowing changes only within the perform interaction is too restrictive. We find this functionality useful and desirable a variety of tasks. For example: automatic initialization of properties, where the first time the entity is presented to a user (without any explicit user interaction with the entity) the entity will compute the default properties. We request WSRP TC to consider relaxing the current model to allow properties to be modified within the getMarkup call. The entityStateChangeOK flag WSRP defined for updating persistent entity state (draft 0.7 section 7.3.1) and the required behavior cannot be achieved without exposing this flag and behavior to the portlet developers. Currently the JSR168 portlet API abstracts portlet developers from dealing with the details of entity creation. A entity can modify properties at any time during a request handling and if this implies an implicit entity (properties record) creation, this is handled transparently by the producer (portlet container). We request WSRP TC to consider an alternate entity copy/creation mechanism that is transparent to the entity and it would not require the entity generating a fault. *Window ID: JSR168 container implementations require identifying the occurrence of the entity in the portal page (what we call portlet window) when processing a request. This is required because an entity may appear more than once in a portal page and the JSR168 container needs to differentiate each one of these requests. We request WSRP TC to consider the introduction of the window ID concept in their protocol in the interactionParams and markupParams data structures. *CSS prefix: JSR168 expert group has already manifested its interest in adopting the WSRP CSS recommendation. We believe this is one of the key things that will enable developers to write portlets with a consistent look and feel in a variety of environments with a minimal effort. We request WSRP TC to consider an alternate naming schema for the CSS attributes that does not denote a specific portlet related technology. Instead of wsia- we propose something like fragment- or portlet-. * Consumer/producer extensions: WSRP defines in many data structures the any parameter as a placeholder to allow consumers and producers to represent extensions. The type of the any parameter is Object allowing vendors to define an arbitrary schema for expressing these extensions. This introduces the complexity for managing the types of these extensions and for the implementation of consumers and producers in Java. For example, static JAX-RPC proxies would not be able to deal with this extensions efficiently having to fallback to dynamic proxies. A producer implementing JSR168 would have to expose these extensions in a non-portable way to portlets. Also, if the JSR168 portlet container has no knowledge about the extensions it may not be able to pass them to the portlet entities. We request WSRP TC to consider restricting the representation of extensions to string name value pairs. * Allowed portlet modes: The WSRP data structures used for handling performInteraction and getMarkup do not carry any information about portlet modes and window states the entity is allowed to change to. JSR168 relies on this type of information to stop a portlet from attempting a change of portlet mode and window state to a non-allowed value. We request WSRP TC to consider adding this information to the interactionPams and markupParams data structures. *Caching WSRP is in the process of defining a comprehensive caching mechanisms. Once fully defined, JSR168 expert group wants to consider it for the JSR168 specification. *Properties Metadata JSR168 expert group is in the process of defining the type of metadata that will be available to producers and consumers. We are aiming for a basic metadata information set that would help consumers and producers to manipulate the properties and provide a generic user interface for them. Once the JSR168 expert group completes this metadata model, we would like WSRP TC to consider it for WSRP entity properties metadata. The current JSR168 expert group schedule targets community review by the end of October. Wed therefore appreciate if WSRP TC can provide an answer on their position on these topics before the end of the month. If WSRP TC believes it will take longer to discuss these issues, would you please give us an estimate on when we should expect an answer. Please let us know if the WSRP TC has further questions on this topics. Thanks and regards. Alejandro & Stefan, JSR168 specification co-leads
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC