[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp-wsia] JSR168 & WSRP aligment
On the issues raised: #1: Under discussion. #2: Properties in WSRP are for the Consumer impacting the entity's state. The entity is not restricted to this being its set of properties in the JSR168 sense. If these are being sent to the Consumer for storage, it will be in the opaque entityState field rather than as explicit Properties. #3: Agreed. WSRP allows a superset of the JSR types. #4: Suggest we add <anyattribute namespace="##other"/> to the definition of a property. This allows extensions much as the rest of the data structures. #5: Agreed #6: The Producer could manage this as part of producing a runtime refHandle. #7: This was put on our backburner to revisit as we got further along in producing a joint spec (& hopefully have an idea of where we are headed in the future ... 2 TCs or 1). It is about time to do that revisit & decide. #8: Since schema is our type language, I prefer to express types in a manner natural to schema. By including <any/> we both allow for future extensions and vendor extensions. The spec encourages that these be typed so that runtimes could generate classes much as is done for the specification's wsdl, but for a runtime to treat them as untyped strings would also be acceptable (it would leaving typing issues to code attempting to exploit the information rather than requiring a general treatment by the runtime stack). #9: This sounds like requesting the Consumer pass the acceptable transitions on getMarkup and performInteraction invocations. I would think this would be problematic as the Consumer's policies may treat this more as a sparse matrix than as disconnected vectors (e.g. view_maximized and mode_edit is acceptable to request, but not view_maximized and mode_help). #10: It sounds like WSRP will be a superset of the current JSR caching scheme. #11: Current proposal does not guarantee that entities are always able to modify their persistent state. They can be ignorant of the copy-on-write semantics though. #12: Such a mapping can easily be managed by the (de)serializers. #13: Extent of localization is under discussion, particularly relative to properties. #14: The table in section 10 of the WSRP spec was introduced to guarantee that endpoints viewing the profile items as a flat space interact in a deterministic way with endpoints taking a more structured view of the data model. Alejandro Abdelnur To: wsrp-wsia <wsrp-wsia@lists.oasis-open.org> <alejandro.abdeln cc: ur@sun.com> Subject: [wsrp-wsia] JSR168 & WSRP aligment 10/18/2002 01:02 PM Dear WSRP TC and JSR168 EG, *This message is being sent to the WSRP TC 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. 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. 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. 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. 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 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. 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. 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? 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. 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. 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. NOTE: current discussion in WSRP on an alternate solution. 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. 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. 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. --------------------------------------------------------------------- ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC