RE: [wsrp] suggested 1.0 errata

-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 25 June 2003 18:15
To: wsrp@lists.oasis-open.org
Subject: Re: [wsrp] suggested 1.0 errata

I think this would have performance implications for the normal case and unexpected side-effects in the direct access case.

Normal case:
- Since the Producer would not know how the Consumer indicates to itself the need to rewrite a resource, the Consumer would have to presume that all resources need to be rewritten (could exclude some based on mime types ... what would it mean to rewrite a gif?) with the resulting performance impact.

[Andre Kramer] I would say that the choice to punt this (resource rewriting) back to the producer is a valid one for consumers. With no {wsrp-requiresRewrite} resource template slot provided, the consumer is saying "I may or may not do re-writing".

Direct access:
- If the Consumer sends a resourceTemplate of {wsrp-url} and the Producer actually needs the resource rewritten (e.g. a JavaScript file), then the Producer is forced to fall back to using the Consumer URL rewriting expression and requiring the Consumer rewrite the markup fragment as well. This would not be expected by developers.

[Andre Kramer] A producer library could certainly treat resources differently, depending on consumer willingness to guarantee re-writing. This would be hidden from developers by the API, except for the performance implications of falling back to consumer re-writing (or having the producer do a dynamic re-write, when serving up the resource, based on a namespace prefix supplied by the consumer and encoded on the resource url), which has the good side effect of discouraging resources that require re-writing ;-)

[Andre Kramer] By making {wsrp-requiresRewrite} optional, we separate out the concern of requiring a consumer to proxy from the guarantee to rewrite resources. We could even set things up to proxy via a standard (non-WSRP) proxy that does no content re-writing, as well as optimise for the no (or transparent) proxy case.

On the value side, how would the Consumer be able to determine that the browser is able to access all resources the Consumer could be directed to?

[Andre Kramer] Consumers and browser both commonly go via a proxy (which may even apply the same access policy). We would see real performance improvements for jpegs, gif, etc if we avoid the (extra) consumer hop.

Both wsrp-url and wsrp-requiresRewrite are currently required in resource templates.
Could we make {wsrp-requiresRewrite} optional?
This would prevent a Producer indicating if a consumer rewrite is required, but:

-- Consumers can choose to be conservative and always re-write.
-- can also allow the consumer to decide whether or not to re-write (based on resource MIME type or file extension).

-- can be used to conditionally proxy resources:
if the consumer decides that browsers can directly access resources,
it can send templates with just "{wsrp-url}" as the value for renderTemplate and secureRenderTemplate.
The effect would be for producers/portlets to directly write-through resource urls into the mark-up.

I believe the ability to pass through resource urls into mark-up,
using "{wsrp-url}" as the (secure)resource template value,
allowing browsers to directly fetch images etc, will be valuable in 1.0.

wsrp message