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

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:

 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 <>

To:


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 APIsClassic 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 managementTo 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