Here are the minutes for this weeks conference
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 attachments?
TODO: Alejandro will bring this up as a point of
discussion for JSR 168.
ii. Multiple Resource Locations (Proxy URLs)
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
b. Portlet Resource
i. Do 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
Is there a new method signature for the interface, such as getResource()
? Or is this embedded in the getMarkup call?
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
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
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 producers.
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
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" or