wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: WSRP / WSIA TC Call Thursday, March 20th 8 am PST / 11 pm EST / 5 pmCET
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Thu, 20 Mar 2003 09:51:49 -0500
The change requests (and current email
discussion summaries) for today's call are:
#138: How does info get to proxied
resources
=> There is a proposal
(worked on in the extended call last week) to define that any cookies the
Producer sets on invocations for a portlet instance are also to be supplied
to resources that portlet instance references subject to the standard cookie
rules as per RFC 2109.
#141: Add previous windowState
and mode?
=> There has been little
discussion about the actual focus of this CR. Is everyone agreed that the
previousMode and previousWindowState fields need to be added back in? The
semantics would be that the Consumer is supplying the values the Portlet
should use for any URL seeking to return to the previous mode or window
state. How the Consumer determines what those values are is implementation
dependent. When and how the Portlet makes use of these values is also implementation
dependent.
#237: CSS Common Control classes
()
=> There has been significant
discussion about whether these are needed. Points I see being made are:
Pro:
These are required in order to achieve common look for standard controls.
Con:
The semantics of what applications choose to do varies so much that this
would be in sufficient to address this area. (wrong level of abstraction).
Suggestion: Place
the concrete classes for common functionality into v1 as this addresses
much of the functionality in a manner that current portlet developers understand
and would likely adopt. Address how more abstract specification of controls
can be done in v2.
Current set of classes suggested
and their semantics:
wsrp-cancel:
abort the current end-user activity.
wsrp-apply: accept and apply the current end-user activity.
Stay in current mode/windowState.
wsrp-ok: accept and apply the current end-user activity.
Exit current mode/windowState.
wsrp-previous: navigate to previous page in the current end-user
activity
wsrp-next: navigate to the next page in the current end-user
activity
#238: No userAgent info => ??
=> Proposal specifies
a value of "" to be supplied whenever the Consumer does not have
the data for this required field.
#239: Rewrite token (wsrp-rewriteURL)
=> This notes that the
wsrp-rewrite token is less unique due to the introduction of wsrp-rewriteResource
portlet URL parameter. Suggestions include:
1. change token to wsrp-rewriteURL
2. change portlet URL parameter
to wsrp-requiresRewrite
#240: Remove Interface.UnsupportedLocale
fault
=> This notes that this
is not likely ever a desired fault. Do we want to define it or just use
the OperationFailed fault for the few cases where it makes sense?
#241: Drop "user-facing"
=> This notes that all
web services needs some level of transformation before processing by a
user agent. Why is WSRP specifically a user-facing web service definition?
Thomas noted that this relates to generation of markup and processing user
interaction with that markup. This is a summary phrase analysts, media,
etc. pick up to understand that point.
Rich Thompson
Interaction Middleware and Standards for Portal Server
IBM T.J. Watson Research Center
Yorktown Heights, NY
(914) 945-3225
richt2@us.ibm.com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]