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


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [wsrp-wsia] Spec v0.92

My take on the open change requests:

138 – How does info get to proxied resources
I think there are two questions we should answer before getting into the details of how to accomplish this.  First, does JSR 168 function strongly suggest we should define something here?  And if not, should we care anyway?  My contention is that the answer to the first question is yes -- as there will be JSR 168 implementations that use the UserId/Categories as a means for communicating access/content capabilities from the portal to the portlet.  It would be highly inappropriate for our protocol to require such a portlet to encode this information so it must be visibily passed all the way through to the client to get it transferred back to the resource.

Once/If we decide to address this problem it seems we have two alternatives to choose from:  
a) extend the existing proxy resource design to support this OR
b) augment/remove our existing proxt resource design with one where resources are executed by calling the portlet using the WSRP protocol.

Personally, I think either of this can be made to work and would be willing to work to solve the issue identified herein in either model.  Andre has provided a basic description for (b).   Here is a quick outline for (a):
1) define a new URL token in the proxy resource URL called sendUserContext.  Its value would be either "true" or "false".  If a value other then a case insensitve "true" is set the value is treaetd as "false".  If the token isn't included the value is treated as "false".  sendUserContext="true" means the portal is to send the UserContext information to the requested proxy resource.  For this release I suggest we only define the capability to send UserId and Categories -- we can deal with Profile later.  UserID would be sent in the http header  "x-wsrp-usercontext-key".  The value of this header would be a single string containing the usercontextKey.  The UserCategories would be sent in the http header "x-wsrp-usercontext-categories.  The value of this header would be a comma delimited list of user categories that apply to the request/userContextKey.

141 – Previous WindowState/Mode
I don't think we will be able to resolve this tomorrow.  Rather we should use a set amount of time to introduce folks to the problem, talk about the requirements I sent out earlier in the day and make some determination on how/whether to proceed with the discussion via e-mail

207 – PortletDescription dependent on UserContext?
I don't think we should add the suggested clarification nor drop passing the UserContext. The word "restrict" defines the right semantics -- you may get less information. By using this word I think there is no confusion that someone would mistakenly provide different values for the same fields to different users.  I don't think we should drop UserContext as it does provide value to the consumer particularly in indicating whether this user can utilze this portlet [or what it can utilize].  Some consumer's will choose to reflect this information  to the user when they are interacting with the portlet toolbox -- e.g. portlet's you can't access won't be displayed in the toolbox on a per user basis.

213 – Require modes, windowstates & userAuthentication are URIs 
I don't think we should adopt this change.  It is not conveniently enforceable as we don't have a well defined means mechanism for a consumer to signal errors to the producer.  What does a consumer do if the requirement isn't met?  Refuse the declaration -- that's okay as a consumer isn't required to map any of the extensions anyway.  The bothersome thing is that the portlet developer will have a hard time debugging why the consumer isn't even offering the opportunity to map these custom modes, etc -- they won't be able to detect whether the consumer provides this capability or there was an error in the format.

If we want to avoid nameclashes I suggest we keep this as a SHOULD and redefine all our values to be URI based and explicitly reserve "wsrp" in this URI namespace.

215 – Delete statement about “private conversational state”
I agree this paragraph is not needed and removing it improves clarity.

230 – Setting navState
I agree the rewording is an improvement however I get a little lost in the parenthetical.  How about "To exist, navigational state must be set explicitly on each interaction or render request or by setting its value upon return from performBlockingInteraction()"?
234 – Delete section B.1
As the issue states the one predefined property isn't really a property, thus should be removed.  Once removed there is no poin in having this section until sometime in the future when we add such properties.

Rich Thompson wrote:
I have reflected the change request resolutions to-date into the spec to 
produce this version. I think the following are all the open items still 
needing resolution:

Left open at the Jan F2F:
 - Sasha to propose language for 1.2.4 about what the protocol enables 
End-Users to do.
 - WSDL subgroup to explore a more "natural" way to carry xml markup. 
(current best is in the markupBinary field)
 - Desire to rename the MarkupType Type. Suggestions have included 
MarkupSupport and MarkupFormat. Any others?

Open Change Requests:
 - 138 – How does info get to proxied resources
 - 141 – Add previous windowState and mode?
 - 207 – PortletDescription dependent on UserContext?
 - 213 – Require modes, windowstates & userAuthentication are URIs (This 
was in the set that was blanket adopted and is reflected in v0.92, but is 
enough different from the discussion of the blanket adopted set that I am 
calling it out here.)
 - 215 – Delete statement about “private conversational state”
 - 230 – Setting navState 
 - 234 – Delete section B.1

The "marked" version has had all of the formatting changes accepted so 
that it is easier to see the insertions and deletions. The second copy has 
had all changes accepted for those who find the change marks distracting.

An item that has been discussed in the WSDL subgroup that also merits 
calling out is that we define two types in our WSDL (StringArray and 
NamedStringArray) that we do not use. They have been left in the 
definition for possible use by extensions.

Rich Thompson


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]