Re: [wsrp-interfaces] Applet resources through WSRP

[Rich Thompson <richt2@us.ibm.com>]

Section 10.2.1.1.3.2 of WSRP v1 lays
the burden on the Consumer to parse and rewrite urls for resources that
set wsrp-requiresRewrite to true. Discussion of this requirement within
the TC limited the burden to string parsing with a replacement of matching
substrings. As such, all textual types, including CSS, should be parsed.
It is likely best if the Consumer is agnostic to the resource's mimetype
other than a determination of what, if any, of the rewritten url needs
to be escaped in order for it to be valid within the containing document.

Rich

Subbu Allamaraju <subbu@bea.com>

03/23/05 09:58 AM

To	wsrp-interfaces@lists.oasis-open.org
cc
Subject	Re: [wsrp-interfaces] Applet resources through WSRP

Rich Thompson wrote:
> 
> It sounds like you are mixing two issues here:
> 
>    1. You have validated that applet use has the same issues
as any
>       other url, but not a large set of new issues.
As a special note;
>       resource urls require full name preservation,
whether it be a .gif
>       or a .jar.
>    2. When Producers use templates for url production and
referenced
>       resources also contain urls, the Producer must
also use the

Can you confirm if the spec requires Producers to rewrite resources it
is serving over HTTP? AFAIR, this is only a requirement on Consumers 
when the MIME type of the resource is text/xml-like. I think the 
requirement on Producers  has implications that we've not discussed
in 
detail.

>       templates on the relevant urls within the resource.
This will
>       become easier with the new getResource operation
(important pieces
>       of data are passed on the invocation), but can
be also done by
>       providing a resolver and passing any required
info on the url (or
>       in cookies, though I would prefer to not explicitly
name that
>       option). Note: this includes namespace resolving
as well as url
>       rewriting.
> 
> 
> Rereading your post, is there also an issue with not all Consumers
> rewriting urls within resources (as per the specs requirements)?
> 
> I think a couple of additions to the FAQ and Primer from this 
> information might be in order.
> 
> Rich
> 
> 
> *"Spector, Artem" <artem.spector@sap.com>*
> 
> 03/23/05 05:03 AM
> 
>                  
> To
>                  <wsrp-interfaces@lists.oasis-open.org>
> cc
>                  
> Subject
>                  RE:
[wsrp-interfaces] Applet resources through WSRP
> 
> 
>                  
> 
> 
> 
> 
> 
> Yes, we’ve found a solution (we work together with Avi) and I’d
like to 
> share it with you.
>  
> Actually there are two challenges when composing consumer-side URLs
for 
> producer-side resources:
> 1.        In some cases the resource name must
be preserved in the 
> consumer-side URL (like .jar for applets)
> 2.        Nested resources – if a css contains
URLs, they must be 
> rewritten as well.
>  
> The solution includes the following aspects:
> 1.        The Consumer modifies the URLs so that
they will end up with 
> the resource names.
> 2.        The Portlets use a standard API to output
resource URLs. In 
> WSRP scenario these calls are intercepted by the Producer, which does
> the necessary conversions (for example, URL writing using templates).
> 3.        If the URL references a resource containing
other URLs (like 
> css or js), the producer replaces the resource URL with a URL pointing
> to a special producer-side servlet. This servlet acts as a filter
when 
> downloading the resource, and rewrites all the URLs it contains.
>  
> For illustration imagine a Portlet called *ExamplePortlet* which was
> deployed with image resource */images/r1.gif*. Its consumer-side URL
> will look like this:
> _http://consumer.com/portal/consumer/resources/r1.gif?producerUrl=http://producer.com/portlets/ExamplePortlet/images/r1.gif_
> 
>  
> If the Portlet has a style sheet resource */css/r2.css*, its URL will
> look like this:
> _http://consumer.com/portal/consumer/resources/r2.css?producerUrl=http://producer.com/producer/resources/r2.css?resourceUrl=http://producer.com/portlets/ExamplePortlet/css/r2.css_
> 
>  
> Now if r2.css contains a reference to r1.gif, then the producer-side
> servlet (producer/resources) will invoke the Producer URL writing
logic 
> for this URL. So eventually the image URL returned to the client within
> the style sheet will exactly as in the first example.
>  
> Regards,
> Artem
>  
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Rich Thompson [mailto:richt2@us.ibm.com] *
> Sent:* Tuesday, March 22, 2005 9:58 PM*
> To:* wsrp-interfaces@lists.oasis-open.org*
> Subject:* Re: [wsrp-interfaces] Applet resources through WSRP
>  
> 
> I have been asked this question now by several people ... has anyone
> tried referencing an applet in markup from a WSRP portlet? If so,
any 
> guidelines that should be shared with portlet developers?
> 
> Rich
> 
> *Subbu Allamaraju <subbu@bea.com>*
> 
> 01/26/05 08:07 AM
> 
>                  
> To
>                  wsrp-interfaces@lists.oasis-open.org
> cc
>                  
> Subject
>                  Re:
[wsrp-interfaces] Apptel resources through WSRP
> 
> 
>  
> 
> 
>                  
  
> 
> 
> 
> 
> 
> 
> Is the Producer returning the Content-Type header? I've not tried
applet
> downloading, but if Content-Type does not work, I would try the
> Content-Disposition header, e.g. with a "inline; filename=foo.jar"
> value. In any case, the Consumer has to proxy these headers to the
browser.
> 
> Regards,
> 
> Subbu
> 
> Klein, Avi wrote:
>  > Hi,
>  >
>  >  
>  >
>  > I wonder if someone has dealt with fetching of applet as
resource.
>  >
>  >  
>  >
>  > Whenever rewriting the URL of the applet, the browser fails
to fetch it
>  > since it expects the URL to end with *.jar and not with
the consumer URL
>  > (result of the rewriting).
>  >
>  >  
>  >
>  >  
>  >
>  > Thanks,
>  >
>  >  
>  >
>  > Avi.
>  >
>