[wsrp-markup] [wsrp][markup] Conf Call Agenda

[Chris Braun <cbraun@silverstream.com>]

Here are the minutes from yesterdays call.

 

 

1. URL Rewriting

    a.  Consumer Rewriting

 

A single marker seems to make the most sense.  This will allow for more efficient parsing.  The consumer will only have to make a single pass.  We should probably use a syntax similar to xml.  XML can not be used do to the fact that URLs are embedded within attributes.  An example of the marker syntax could be:

 

{startMarker wsia:urlType=action wsia}portletParam1=Dog&portletParam2=Cat{endMarker}

 

The string contained between the begin and end marker are parameters specified by the portlet entity.  We should use the & as the field seperator because developers are familar with its use.  In most cases the consumer will simply be converting the parameters into a query string, so this simplifies this process.

 

Some portlet vendors have the noting of portlet modes.  A portlet mode indicates to the portlet entity how what markup should be displayed.  Modes can be specified using the portlet entity specific parameters within the URL.  Markup parameters may also be used.  The concensus was that we do not need to add WSRP protocol specific features to handle portlet modes.  It should also be mentioned that modes seems to be a container specific notion, and some portal implmenters may not have this notion.

 

Portlet window states (minimized, maximized, and normal) are supported by most portal vendors.  It may make sense to add this notion to he WSRP interface.  The consumer needs to know how to display the portlet.  This is differnt from modes, where the entity itself controls the markup to be displayed. 

 

Action Item: Bring this up at the next WSRP interfaces meeting.

 

URL encoding is left up to the entity.  It should also be the responsibility of the entity to decode any possible client parameters.  The issue was raised that some server side APIs (IIS for example) always perform a URL decode of parameters.  Some consumer implmentations may find it a hassle to pass un-decoded params to the producer.   We need to decide if the consumer should always pass back the same url encoded parameter, and to prohibit the consumer from decoding them. 

 

If the entity is required to do both encoding and decoding then it must be aware of which encoding code was used to encode the URL.  Is it safe to assume that since the entity encoded the URL then it should know the code for decoding?  Or does the code need to be passed along with the request/response document?  I think we can assume that the client locale and device information will be supplied to the entity, this should be enough to determine the code to use.  We should continue this discussion next week.

 

Action Item:  Investigate if it is possible to retrieve un-decoded parameters using IIS.  This is definately doable in Servlet 2.2 and greater.

 

 

    b.  Producer Writing

 

WSRP should use a templating mechanism in which the producer receives a template from the consumer.  The producer will then fill in the template markers.  Markers in this case would consist of {entityHandle}, {markupParams}, {clientParams}, etc.

 

 

 

2. Render and Action URLs

 

The interfaces subcommittee has added the notion of render and action requests.  We will need to add these as seperate URLtypes (wsia:urlType).

 

 

3. Resource URLs

    a. Caching

 

We will leave caching of resources up to the http protocol.  There is no need to provide our own semantic of resource caching.

 

    b. Rewriting

 

Need to add a URL attribute, such as wsia:rerwriteResource, to indicate to the consumer wheather or not a specific resource should be parsed for rewriting.  Most resources will not require rewriting (images, pdfs, etc.) so by default the consumer will not rewrite a resource unless explicetly told to do so by the producer entity by using the wsia:rerwriteResource attribute within the resource URL.

 

 

    c. Multiple Resource Locations

 

Moved topic to next weeks agenda.

 

4.  Namespacing

 

Moved topic to next weeks agenda.

 

5.  Marker for Efficient Parsing

 

Moved topic to next weeks agenda.