[wsrp-markup] [wsrp][markup] Aug 14 Conf Call Minutes

Here are the minutes for this weeks conference 
call.

 

Attendees:

Chris Braun

Michael Freedman

Alejandro Abdelnur

Carsten Leue

Eric Van Lydegraf

Andre Kramer

 

 

Discussion:

 

1. Resource URLs

    a. Proxy Resource 
URL

        
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 
WSRP.

 

 

    b. Portlet Resource 
URL

        i. Do we need 
another URL type to distinguish between proxy and portlet entity 
recourses.  Such as wsia:urlType=resource and 
wsia:urlType=proxyresource

 

Tabled until next week.  May 
be dependent on how/if binary attachments will be handled within 
markup.

 

        ii.  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.

 

2.  Attachments

    a.  Soap Vs. 
Dime            

        - Soap 
Dependency

        - Effect on 
WSDL Binding info

        - 
Implementation Specific?

 

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.

 

TODO:

    Alejandro:  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, markupResponse)?

 

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:mode=edit|help|configure|view and 
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 
extension mechanism.

 

TODO:

 

Interfaces Group:  Add properties to performInteraction for 
windowState and Mode support

 

 

Postponed Topics

- 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 "save".