OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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



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]