Discussion of Rewritable Resource URLs and Should the path be rewritable

[Nathan Lipke <nathan.lipke@oracle.com>]

When dealing with client rewritable resource (both getResource() and proxied) URLs the most contentious issue has been whether the extension should allow a portion of the path to be rewritten. I would like to start a discussion around this. Based on the discussion I will post a ballot later in the week to more formally record people's thoughts on the matter.

Note: other markup URLs do not contain addressable paths, therefore while they may be covered by the extension, their paths will NOT be rewritable.

To start off the discussion, I will give my opinion (as an individual SC member) on the subject.:

It is my firm belief that WSRP should work with all common web technologies. This does NOT mean WSRP needs to "support" every new technology that comes into fashion. However, we should do our best to not get in the way. In general WSRP should be transparent and minimally invasive to portlets  and their developers. While this is a lofty goal, I think we can greatly improve the development experience when it comes to RIA (Rich Internet Application) style portlets. Currently non-client-rewritable URLs (both path and parameters) is a major impediment to using RIA (and classic) technologies.

Technologies include:

• Classic
  
• Style sheets
• Classic HTML (web 1.0)
  

• RIA
  
• Common script frameworks including:
  
• ASP.NET Ajax Framework
  
• Dojo
• YUI
• GWT
• script.aculo.us
• Prototype
• MooTools
• jQuery
• Spry
• Cean
  
• ...
• Embedded plugins
• Flex
• Flash
• Silverlight
• ...
  
• RESTfull APIs

Classic technologies (HTML, CSS) both can make use of relative URLs (e.g. <img src="javascript:void(0);"/>) which the browser will automatically rewrite.

RIA technologies use more sophisticated client rewriting, for a number of use-cases, including:

• Module loading (relative to the base script)
• Human Readable/Well Designed URls, for:
  
• Simplified client development
  
• Improved cachability
  
• Search Engine optimization
• State management

To support all these use-cases I think we need to allow for path manipulation.

The drawback to this is the extension will have to specify URL formats on the client. So far the committee has avoiding do this as it places a burden on the consumer. This may place an additional burden on the consumer as it may cause the consumers  to modify its URL patterns. Additionally there may be security concerns with allowing the client to addresses certain resources. However, consumer and/or producer policies as well as limits on rewriting may alleviate this concern.


Feedback would be greatly appreciated.

Thanks,

Nate