wsrp-interfaces message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsrp-interfaces] Applet resources through WSRP
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp-interfaces@lists.oasis-open.org
- Date: Mon, 28 Mar 2005 09:50:28 -0500
I would agree with Yossi and would suggest
either FAQ or Primer content in this area. In particular, I would suggest
the following rewording of Artem's summary:
The Producer responsibility
regarding URLs within resources is as follows:
1. If
the Producer returns the resource URL with wsrp-requiresRewrite=true, then
the URLs in this resource must be ready for the Consumer rewriting (contain
wsrp-rewrite tokens).
2. If
the Producer returns the resource URL with wsrp-requiresRewrite=false,
then all URLs in this resource must be ready for interpretation by the
user agent (i.e. either be absolute URLs or produced using Consumer-supplied
templates).
3. Any
other option is not compliant.
Rich
"Yossi Tamari"
<yossi@giloventures.com>
03/28/05 07:32 AM
|
To
| <wsrp-interfaces@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [wsrp-interfaces] Applet
resources through WSRP |
|
The spec says the following
about portlet markup (not resources): “If
a Portlet is unable to completely write the portlet URLs for its markup,
it MUST set the requiresUrlRewriting flag in the returned MarkupContext
structure to “true”.”
However, the same is not said
of resources, naturally, since they will not often include “portletURLs”
(URLs back into the portlet). While it may be underspecified for resources,
the way I would view it is that there must not be any relative URLs, but
absolute URLs which point outside the consumer are allowed – After all
we would not want to prevent a portlet/resource from containing a direct
link to Google, right?
In other words, I agree with
your 1-3, but with the definition of “final” as “pointing to the consumer
or a third party web site”.
Yossi.
From: Spector, Artem [mailto:artem.spector@sap.com]
Sent: Monday, March 28, 2005 1:51 PM
To: Yossi Tamari; wsrp-interfaces@lists.oasis-open.org
Subject: RE: [wsrp-interfaces] Applet resources through WSRP
Would it be correct to summarize
the Producer responsibility in rewriting of URLs inside resources as follows?
1. If
the Producer returns the resource URL with wsrp-requiresRewrite=true, then
the URLs in this resource must be ready for the Consumer side rewriting
(contain wsrp-rewrite tokens).
2. If
the Producer returns the resource URL with wsrp-requiresRewrite=false,
then the URLs in this resource must be final (pointing to the Consumer).
3. Any
other option is not compliant.
Artem
From: Yossi Tamari [mailto:yossi@giloventures.com]
Sent: Sunday, March 27, 2005 7:52 PM
To: wsrp-interfaces@lists.oasis-open.org
Subject: RE: [wsrp-interfaces] Applet resources through WSRP
I do not see why the current
situation is confusing, but could you please explain what are you suggesting?
To remove either producer or consumer side rewriting from the spec? (Which
one?) Only for resources?
I guess your confusion may
be result of the fact that in 1, you deal with resources that are not WSRP
compliant to begin with. In a “pure” WSRP world, the resources would
already include the “wsrp-rewrite?” URLs (at least in the sense that
they are dynamic and add use URLs when called in a certain way). Because
of legacy resources, you encounter the need to actually parse the resource
for other tokens and replace them with rewritable links. This is not something
the spec deals with at all, since there is no general solution for it (e.g.
if the resource contains JavaScript, it is possible that the URL is constructed
dynamically in such a way that the parser will not recognize the URL).
The filter that was suggested here earlier is a best-effort attempt to
solve this, which is an acceptable implementation, but it is not part of
the spec, or even suggested by it.
Yossi.
From: Spector, Artem [mailto:artem.spector@sap.com]
Sent: Sunday, March 27, 2005 7:27 PM
To: wsrp-interfaces@lists.oasis-open.org
Subject: RE: [wsrp-interfaces] Applet resources through WSRP
Yes, I can see your point,
and it’s a good opportunity to return to the real question:
What should be the Producer
role in rewriting URLs within a resource? I can see two options:
1. the
Producer wraps the resource and “prepares” the URLs for the Consumer-side
rewriting (or uses the resource templates)
2. the
Produce does not wrap the resource and the Consumer does the rewriting
by itself
IMO the situation when both
options are possible is confusing, because the Consumer implementation
will have to rely on the Producer implementation (and not on the spec as
it should be). Shouldn’t the spec be more explicit here and allow only
one of these options?
Artem
From: Yossi Tamari [mailto:yossi@giloventures.com]
Sent: Sunday, March 27, 2005 6:19 PM
To: wsrp-interfaces@lists.oasis-open.org
Subject: RE: [wsrp-interfaces] Applet resources through WSRP
Hi Artem,
If I understand you correctly,
you suggest that the consumer will parse the resource looking for text
like “url(images/bcg,gif)” and rewrite it.
While it is compliant to the
spec to do so (the spec does not forbid it), the portlet/producer that
returned this resource is not compliant. It cannot assume that the consumer
will parse the resource for anything other than “wsrp-rewrite?”.
This can be implemented as
a vendor specific extension, so the producer does not need to parse when
serving consumer from that vendor, but in “normal operation” the producer
has to assume the consumer does exactly what the spec requires, and not
more.
Yossi.
From: Spector, Artem [mailto:artem.spector@sap.com]
Sent: Sunday, March 27, 2005 4:58 PM
To: wsrp-interfaces@lists.oasis-open.org
Subject: RE: [wsrp-interfaces] Applet resources through WSRP
Assume the Producer doesn’t
rewrite the content of the CSS and the Consumer gets the original content:
backimage{
background-image:url(images/bcg.gif);
}
The point is that this happens
in the context of consumer serving the client request
http://consumer/portal/resources/my.css?wsrpUrl=http://producer/portal/applications/MyPortlet/css/my.css&requiresRewrite=true
This means that at time of
parsing of the style sheet content the Consumer knows its absolute URL
(wsrp-url parameter of the current request).
Knowing the absolute URL of
the style sheet and having a URL relative to this style sheet, the consumer
can transform images/bcg.gif to
http://producer/portal/applications/MyPortlet/css/images/bcg.gif
That’s what I mean saying
“enough information”. Wrapping this result with the Consumer URL and
requiresRewrite=false(or true) is relatively straightforward, so the Client
will get
backimage{
background-image:url(/portal/resources/bcg.gif?wsrpUrl=http://producer/portal/applications/MyPortlet/css/images/bcg.gif
&requiresRewrite=false);
}
An advantage of this approach
is better performance (because the resource content is parsed only on the
consumer side) and simplicity (because there’s no need to define producer-side
wrapper).
I don’t think that this approach
is “less compliant” to the v1.0 spec than producer-side resource wrapper.
Artem
From: Mike Caffyn [mailto:mike@netunitysoftware.com]
Sent: Thursday, March 24, 2005 8:36 PM
To: wsrp-interfaces@lists.oasis-open.org
Subject: Re: [wsrp-interfaces] Applet resources through WSRP
I see how the consumer would rewrite the
url in the portlet markup
<link rel="stylesheet" type="text/css"
href=""wsrp-rewrite?wsrp-url=http://producer/portal/applications/MyPortlet/css/my.css&requiresRewrite=True"\>
and then the stylesheet itself contains
backimage {
background-image:url(wsrp-rewrite?wsrp-url=http://producer/portal/applications/MyPortlet/images/bcg.gif&requiresRewrite=false);
}
but not if the stylesheet contains
backimage {
background-image:url(wsrp-rewrite?wsrp-url=images/bcg.gif&requiresRewrite=false);
}
This is the bit I don't get "The
consumer has has enough information to convert relative URL images/bcg.gif"
This part I do not see as being part of the
WSRP spec and consumers required to process relative to absolute urls.
If the producer has a wrapper for resource
css stylesheet that takes the
backimage{
background-image:url(images/bcg.gif);
}
and converts it to
backimage {
background-image:url(wsrp-rewrite?wsrp-url=http://producer/portal/applications/MyPortlet/images/bcg.gif&requiresRewrite=false);
}
before it is sent back to the consumer then
everything works fine.
Mike
----- Original Message -----
From: Spector,
Artem
To: wsrp-interfaces@lists.oasis-open.org
Sent: Thursday, March 24, 2005 11:11
AM
Subject: RE: [wsrp-interfaces] Applet
resources through WSRP
Please note that in my example
the wsrp-url is absolute (step 4), though the Portlet code operates with
relative URLs.
As for the relative urls contained
in other resources, they can be rewritten by the Consumers without any
assistance from the Producers.
I’ve tried to show that when
the Consumer processes the request
GET http://consumer/portal/resources/my.css?wsrpUrl=http://producer/portal/applications/MyPortlet/css/my.css&requiresRewrite=true
and parses the input stream,
it has enough information to convert relative URL images/bcg.gif into
something like
“/portal/resources/bcg.gif?wsrpUrl=http://producer/portal/applications/MyPortlet/images/bcg.gif&requiresRewrite=false”
Doesn’t the spec require the
Consumers to respect the wsrp-requiresRewrite flag?
Artem
From: Mike Caffyn [mailto:mike@netunitysoftware.com]
Sent: Thursday, March 24, 2005 5:08 PM
To: wsrp-interfaces@lists.oasis-open.org
Subject: Re: [wsrp-interfaces] Applet resources through WSRP
Currently the spec says wsrp-url for a resource
must be an absolute address, so I would guess not many consumers would
support this relative address as you specify. I have also noticed not many
consumers support rewriting of resources that are referenced in another
resource. For example an CSS stylesheet that contains another CSS stylesheet
reference.
Currently the producers would have to be
involved in the generating the urls for images within the markup and in
the resource processing of a css stylesheet (unless they contained absolute
addresses, this would be a nightmare in deployment). All they would be
doing is replacing the relative address with an absolute address so it
is wsrp specific when required ie not running in local mode.
Mike
----- Original Message -----
From: Spector,
Artem
To: wsrp-interfaces@lists.oasis-open.org
Sent: Thursday, March 24, 2005 9:15
AM
Subject: RE: [wsrp-interfaces] Applet
resources through WSRP
Let’s look into the flow for
a simple example, when a Portlet MyPortlet was deployed with a style
sheet (relative path “css/my.css”) which contains a URL of a background
image “images/bcg.gif”.
1. The
Portlet begins with the local path and outputs to the response stream the
string: “css/my.css”.
2. The
response wrapper constructs a relative URL which contains the servlet path
(based on the request). The result looks like this: “/portal/applications/MyPortlet/css/my.css”
Now we have two different scenarios:
local portal and WSRP.
Local Portal scenario:
The page content includes the
URL as it was created on step 2: “/portal/applications/MyPortlet/css/my.css”
Note that the image URL inside
the css is still “images/bcg.gif”.
Now for these two resources
the browser issues the following requests:
GET http://producer/portal/applications/MyPortlet/css/my.css
GET http://producer/portal/applications/MyPortlet/images/bcg.gif
Everything is OK in this case.
WSRP scenario:
Here we have some additional
steps before the content gets to the browser:
3. The
Producer response wrapper converts the URL to absolute (based on the request)
and the result is: “http://producer/portal/applications/MyPortlet/css/my.css”
4. The
Producer embeds the absolute URL into the resource template (or the Consumer
rewrites the URL): “/portal/resources/my.css?producerUrl=http://producer/portal/applications/MyPortlet/css/my.css&rewriteUrl=true”
When the page is downloaded
to the browser, it issues the following request:
GET http://consumer/portal/resources/my.css?producerUrl=http://producer/portal/applications/MyPortlet/css/my.css&rewriteUrl=true
Now the Consumer must parse
the content of the resource being downloaded and rewrite the URLs.
Obviously the result of rewriting
of “images/bcg.gif” should be:
“/portal/resources/bcg.gif?producerUrl=http://producer/portal/applications/MyPortlet/images/bcg.gif&rewriteUrl=false”
But the Consumer cannot compose
it because it doesn’t know the producer-side servlet path (highlighted).
On the second thought the Consumer
can compose the result URL using the producer servlet path taken from the
current request, assuming the inside URLs are relative. This could work!
I’ll try it out…
Artem
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Wednesday, March 23, 2005 9:29 PM
To: wsrp-interfaces@lists.oasis-open.org
Subject: Re: [wsrp-interfaces] Applet resources through WSRP
If people don't mind, lets walk into this carefully (I am certainly not
an expert on how portals manage urls).
Consider, for the local portlet case, how the eventual urls gets constructed:
1. The
Portlet begins with a local/relative URL; example: relative path to a CSS
file
2. The
Portal adds to the URL items such as host and context path to form an absolute
url
3. The
loaded resource contains a local/relative URL; example: a style specifies
a background gif
4. The
xxx forms the absolute url.
If xxx in step #4 is the browser, I would think it would use the baseURL
of the page and therefore construct an absolute url which failed to point
at the gif. If instead it uses the url of the css file, I would suspect
the relative reference to work (including working with WSRP).
if xxx in step #4 is the Portal, I would think it already has a facility
for preprocessing resources that could be leveraged to generate WSRP type
urls using either Consumer url rewriting or Producer template processing.
Rich
"Spector, Artem" <artem.spector@sap.com>
03/23/05 11:31 AM
|
To
| <wsrp-interfaces@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [Fwd: Re: [wsrp-interfaces]
Applet resources through WSRP] |
|
Yes, the “entire user experience” was our purpose. From that point of
view the URL string of some resource should be the same whether this URL
“originates” from a Portlet code or from a resource text.
Usually building of Portlet-originated URL takes 3 steps:
1. The
Portlet begins with a local/relative URL
2. The
Producer adds to the URL the servlet path (including host and context path)
3. The
Consumer wraps the producer-side URL with its own servlet path (using templates
or consumer-side rewriting).
Now let’s consider a resource file containing some local URL. If the Producer
just indicates wsrp-requiresRewrite, then the Consumer has to deal with
this local URL directly. Returning to the 3-step example, the step 2 is
missing.
Honestly I don’t see how the Consumer-side parsing/rewriting of resource
content can be implemented without any Producer assistance.
Artem
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Wednesday, March 23, 2005 5:28 PM
To: Subbu Allamaraju
Subject: Re: [wsrp-interfaces] Applet resources through WSRP
I agree with the issues you raise. However, if the Producer is doing the
url production, it must do it in a manner that will work for the entire
user experience ... including resources. The idea would be to point out
these issues to implementers and provide some guidance on how they could
be addressed. One of the options could be to use templates for url production
in the markup and then mark resource as needing Consumer url rewriting,
but Artem points out that other options exist if the Producer is willing
to manage things properly.
Rich
Subbu Allamaraju <subbu@bea.com>
03/23/05 10:17 AM
|
To
| wsrp-interfaces@lists.oasis-open.org
|
cc
|
|
Subject
| Re: [wsrp-interfaces] Applet resources
through WSRP |
|
I agree with that. I'm referring to your comment "the Producer must
also
use the templates on the relevant urls within the resource". Such
a
requirement, if placed, would assume that the Producer has control over
resource serving, and that it has the templates handy. Both of these may
not be true in most cases.
Subbu
Rich Thompson wrote:
>
> 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.
> > >
> >
>
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]