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

Minutes from August 7 WSRP Markup Call

 

1. URL Rewriting

    a.  Consumer URL 
Rewriting

        - Complexity 
differences between Resource and Action URLs

 

[discussion]

It was discussed that requiring a consumer to 
rewrite (Namespacing and URLs) proxied resources would put a large burden on the 
consumer.  For the first rev of the spec we will require that the consumer 
rewrite portlet entity markup only.  It will be the producers 
responsibility to handle static resources.  One solution is to allow for 
the getmarkup call to return resources other than markup.  Consumer URL 
rewriting can then occur on the content provided by getMarkup.  
We should also add a property to the getMarkup response to indicate weather or 
not Consumer URL rewriting should be done on the returned resource.

 

        - Marker 
Syntax

    b.  URL Encoding/Decoding 
(http://www.w3.org/TR/html40/appendix/notes.html#non-ascii-chars)

 

[discussion]

For all WSRP URLs we will require that the URLs be 
encoded in UTF-8 and then escaped.  We will provide a reference to the 
above URL in the spec.

 

2.  Markup Encoding

    a.  Consumer provides list 
of accepted encoding charsets.  Rather than requiring UTF-8, this would be 
more flexible.  Where a consumer may choose to accept UTF-8 as well as a 
client specific encoding.  

 

[discussion]

The Consumer will provide a preferred a preferred 
charset on the request to the producer entity.  The producer will then have 
to encode the markup with that charset.  The Consumer may also perform 
charset conversion.  If the consumer provides this feature a property will 
be set in the registration parameters set to true.  False will be the 
default.  If the Consumer provides charset conversion then a portlet is 
free to generate markup in any standard charset encoding.  This will need 
to be added to the Meta-Data area of the spec as well as the markup 
section.

 

3. Resource URLs

 

[discussion]

Three types of Resource URLs:

1.  Direct URL

    A simple URL to any resource on the web, neither proxied 
or served by the portlet entity.

2.  Portlet Entity URL (link to portlet which serves a resource via 
getMarkup)

    A URL pointing back to the portlet entity which tells 
the consumer to execute getMarkup to retrieve a specific resource

3.  Proxied URL

    A URL to a resource somewhere on the web (perhaps on the 
portlet entities host) which must be proxied by the consumer so that clients 
retrieve all resources for a particular portlet entity from the consumer.  

 

There was some discussion that Proxied URLs are not required if we allow 
portlets to serve resources themselves.  The idea is that the producer 
container can handle the resources.  This would further simplify the 
consumer container.

 

TODO:  We should identify if there are use cases where a proxied URL 
would be required.  Do we need both portlet URLs and proxied URLs?  

 

4. Attachments

    a. Sending in response (use case)

 

[discussion]

Portlet entities should be able to provide markup and other resources via 
the getMarkup call.

 

    b. Posting in request (use case)

 

[discussion]

A portlet entity should be able to post large binary content back to itself 
from the consumer.  An example of this is posting multi-part form encoded 
content.

 

    c. SOAP vs. DIME

 

[discussion]

Soap attachments are bound to SOAP where as WSRP should not be bound to a 
specific protocol.  DIME is supported by .NET while SOAP is supported by 
JAX-RPC.  It seems likely that JAX-RPC will support both, down the 
road.  

 

TODO: Carsten will investigate the status of these specifications and relay 
the information to the group.

 

Postponed topics

 

- Window States

    a.  Can portlet entities render action links which 
change window state?