Re: [wsrp-interfaces] Discussion of Rewritable Resource URLs and Should thepath be rewritable

[Richard Jacob <richard.jacob@de.ibm.com>]

we interpret it differently and handle
those cookies in two layers.
A cookie set by a portlet or the producer
during a non-initCookie() call is distributed to all parties matching the
cookie domain rules.
Typically we think that a portlet would
expect to have cookies handles just like in the normal web world and this
would include to distribute it even to other nodes no being the producer
if the cookie domain rules require that.
InitCookie scoping is somewhat weird
that it was merely introduced to handle jsession ID setup for web applications
on the producer side and since every wsrp group might have its own jsession
id, we needed to scope them (in point of view one of the ugliest parts
in the spec ;-) ).

Note that following cookie domain rules
might also break if the portlet/producer sets path information on the cookie
(picked up from his local deployment) but another path is used to address
that portlet via a web service call (naturally the WS servlet path).
So this use case breaks or at least
can not be cleanly implemented. But we saw it as an edge case in the past.

Mit freundlichen Grüßen / Kind regards
Richard Jacob
Team Lead Portal Standards & WCM development WSRP Standardization Lead
IBM Software Group, WPLC
WSS Websphere Portal Foundation Development 1
Phone:	+49-7031-16-3469	IBM Deutschland
E-Mail:	richard.jacob@de.ibm.com	Schoenaicher Str. 220
		71032 Boeblingen
		Germany
IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: Martin Jetter Geschäftsführung: Erich Baier Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294

 

From:	Nathan Lipke <nathan.lipke@oracle.com>
To:	wsrp-interfaces@lists.oasis-open.org
Date:	02/22/2009 08:33 PM
Subject:	[wsrp-interfaces] 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=""../images/logo.gif"/>)"
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