Here are the minutes for this weeks
Eric Van Lydegraf
1. Resource URLs
a. Proxy Resource
i. Versus Portlet Entity Resources
JSR 168 does not have the notion of embedding
large binary content within the markup. JSR 168 only addresses
portlets rendering markup or redirecting to a web resource. Does it
make sense for a local portlet to be accessing the containers response
output stream. This does seem contradictory to the portlet
model. This discussion will be continued in the next JSR 168 conf
call as well as the FTF, which is in two weeks. We will try to
incorporate a model for WSRP based on the information that we learn
from the JSR 168 conversations. The key question that has
to be answered is: Do we support the notion of embedding binary data
within the markup of a portlet's markupResponse or would it make more
sense to create a new interface, getResource, for sending binary
TODO: Alejandro will bring this up as a point
of discussion for JSR 168.
ii. Multiple Resource Locations (Proxy
It was discussed that it may be worthwhile to specify a mechanism
from portlets to be able to use relative references. In a complex
producer container, such as a JSR 168 container, the resource URL is
constructed by the container. This makes the actual
URL transparent to the developer. For simple producers the URLs
would have to be fully qualified. Thus, all Proxy URLs must be fully
qualified. weather this is handled by the producer or the actual
entity is out of the scope of WSRP.
b. Portlet Resource
we need another URL type to distinguish between proxy and portlet entity
recourses. Such as wsia:urlType=resource and
Tabled until next week. May
be dependent on how/if binary attachments will be handled
ii. Is there a new method signature for the interface, such as
getResource() ? Or is this embedded in the getMarkup
Tabled. Continue discussion after JSR
168 has a chance to discuss this.
a. Soap Vs.
Effect on WSDL Binding info
SOAP has issues with carrying large data
blocks within the body of a soap message.
We will allow both SOAP-Attachments and DIME.
The idea is that we provide 3 WSDL binding schemas: A simple binding
schema which does not include support for attachments; A binding
schema which defines SOAP attachments; A schema which defines DIME
attachments. Since DIME requires interface additions we can add
these to the main WSDL interface as optional.
We won't make the requirement that the
consumer supports both attachment types. For example .NET consumers
will not support SOAP attachments and a JAX-RPC container may not support
DIME. We will require that the consumer support one of the WSDL
bindings with support for attachments. We will also require that the
consumer must support the simple WSDL binding.
Follow up with JAX-RPC to understand possible
support for DIME.
Carsten: Prototype (POC)
using optional DIME tags within a non-DIME consumer.
Carsten and Andre:
Write-up describe consumer relationship with attachment binding:
Dynamically created proxies and Pre-created proxies
b. Where is the
attachment embedded for both a response and a request (i.e.
interactionContext, interactionResponse, markupContext,
The current thought is that we embed the
request attachment within the interactionContext and the response
attachment within the markupResponse. We should investigate how this
would map to the JSR 168 local portlet world.
- Window States
Can portlet entities render
action links which change window state?
Portlet entities should be able to render markup links that will
enable user to change window state and portlet mode. To enable this
we need to define well known property names and values. For example
wsia:windowState=normal|minimized|maximized. This will be added to
the producer and consumer URL rewrite semantics.
We also need to define an extensibility mechanism so that custom
modes (or possibly window states) can be introduced by portlet
The performInteraction interface should be enhanced to allow entities
to programmatically set window states and portlet modes.
Registration MetaData may need to include a semantic for
providing supported modes and window states as well as custom
mode information. We may need to formalize a custom
modes/window state extension mechanism.
Interfaces Group: Add properties to performInteraction for
windowState and Mode support
- URL encoding (Revisit)
- Button and Label consistency across portlets
How can configuration
interfaces maintain a consistent look and verbiage across entities.
For example when saving customize information should buttons read "apply"