Discussion of Rewritable Resource URLs and Should the path be rewritable

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