OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[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