Comments at 3. Resource URLs
-----Original Message-----
From: Chris Braun
[mailto:]
Sent: Thursday, August 08, 2002
10:01 AM
To: WSRP-Markup
Subject: [wsrp-markup]
[wsrp][markup] Aug 7 Conf Call Minutes
Minutes from August 7 WSRP Markup Call
1. URL Rewriting
a. Consumer URL
Rewriting
-
Complexity differences between Resource and Action URLs
[discussion]
It was discussed that requiring a consumer to
rewrite (Namespacing and URLs) proxied resources would put a large burden on
the consumer. For the first rev of the spec we will require that the
consumer rewrite portlet entity markup only. It will be the producers
responsibility to handle static resources. One solution is to allow for
the getmarkup call to return resources other than markup. Consumer URL
rewriting can then occur on the content provided by getMarkup.
We should also add a property to the getMarkup response to indicate weather or
not Consumer URL rewriting should be done on the returned
resource.
- Marker
Syntax
b. URL Encoding/Decoding
(http://www.w3.org/TR/html40/appendix/notes.html#non-ascii-chars)
[discussion]
For all WSRP URLs we will require that the URLs
be encoded in UTF-8 and then escaped. We will provide a reference to the
above URL in the spec.
2. Markup Encoding
a. Consumer provides
list of accepted encoding charsets. Rather than requiring UTF-8, this
would be more flexible. Where a consumer may choose to accept UTF-8 as
well as a client specific encoding.
[discussion]
The Consumer will provide a preferred a preferred
charset on the request to the producer entity. The producer will then
have to encode the markup with that charset. The Consumer may also
perform charset conversion. If the consumer provides this feature a
property will be set in the registration parameters set to true. False
will be the default. If the Consumer provides charset conversion then a
portlet is free to generate markup in any standard charset encoding.
This will need to be added to the Meta-Data area of the spec as well as the
markup section.
3. Resource URLs
[discussion]
Three types of Resource URLs:
1. Direct URL
A simple URL to any resource
on the web, neither proxied or served by the portlet entity.
2. Portlet Entity URL (link to portlet
which serves a resource via getMarkup)
A URL pointing back to the
portlet entity which tells the consumer to execute getMarkup to retrieve a
specific resource
3. Proxied URL
A URL to a resource
somewhere on the web (perhaps on the portlet entities host) which must be
proxied by the consumer so that clients retrieve all resources for a
particular portlet entity from the consumer.
[Eric VanLydegraf] I would
like to confirm my understanding of 2 &
3
[2] - are
we talking specifically WSRP/SOAP only for retrieving Resources
?
Then you have to consider the cost
of SOAP marshalling and
unmarshalling (Unless the attachments issue works
out)
Streaming URL resources wouldn't
work
The Producer has to be willing or able to wrap all
resources around SOAP - given that many resources will
probably
already be deployed on FTP or HTTP servers in
possibly alternate locations than the WSRP Producer container might be hard
pressed to support this.
On the positive side it certainly keeps everything in
the WSRP protocol which has a real nice appeal ;)
[3] Proxied URL - Consumer makes URL protocol connection on
behalf of client and returns URL content to
client.
- Browser URL location and url's on the same page are
consistent ("Consumer URL Branding")
- cookies and security can be
kept at Consumer and used for proxy services.
e.g. Basic Auth, or Form Based Auth doesn't have to
be repeated for external URL's ( kind of poor mans Single Sign On
(SSO)
so user is only prompted once (assuming Consumer and
Producer have worked out security credential sharing (e.g. LDAP) or secure
token passing, or consumer is holding on to a password vault of Producer user
passwords)
A 3rd party SSO service can alleviate the multiple
logins, but that may not be available to Consumer or Producer so Proxy would
have to be used.
-
Resource is not directly available to client but is directly available to
Consumer
Note:
one motivation for Consumer brokerage of resource access is
Auditing for consumer
= can track resource downloads or usuage, site exit
points (Usage tracking, or producer auditing for contractual
validation purposes aka proof for lawyers - note a 3rd party source is more
likely but that would just mean somebody else is doing the proxying instead of
the consumer )
[Eric VanLydegraf]
There was some discussion
that Proxied URLs are not required if we allow portlets to serve resources
themselves. The idea is that the producer container can handle the
resources. This would further simplify the consumer
container.
TODO: We should identify if there are use
cases where a proxied URL would be required. Do we need both portlet
URLs and proxied URLs?
4. Attachments
a. Sending in response
(use case)
[discussion]
Portlet entities should be able to provide markup
and other resources via the getMarkup call.
b. Posting in request
(use case)
[discussion]
A portlet entity should be able to post large
binary content back to itself from the consumer. An example of this is
posting multi-part form encoded content.
c. SOAP vs.
DIME
[discussion]
Soap attachments are bound to SOAP where as WSRP
should not be bound to a specific protocol. DIME is supported by .NET
while SOAP is supported by JAX-RPC. It seems likely that JAX-RPC will
support both, down the road.
TODO: Carsten will investigate the status of
these specifications and relay the information to the group.
Postponed topics
- Window States
a. Can portlet entities
render action links which change window
state?
