[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp-wsia] Issues for 12/5 call
There have been several issues appear over the past week on the email list (I am finally reading them). Lets work through: #160: Template fields should camel lower casing => Had been noted by others as well ... current version uses actionTemplate ... #161: usesMethodGet today means - I have it or I don't. I would like to add a new one, which says I'll use methodGet only if the Consumer supports it, otherwise I'll fall back on other methods. This enables the Producer to support all Consumers. => proposal is to: 1. add Consumer metadata - "methodGetSafe" (boolean) 2. make usesMethodGet triState - add value for "adaptsToConsumer" => If the first boolean is added, doesn't the second just become equivalent of dynamically returning Consumer.methodGetSafe for usesMethodGet? #159: In all cases where locale/language needs to be specified, this should be optional. In some cases, I just don't know what the locale is. Even HTTP allows not specifying locale. => LocalizedString is the one case where I don't think this should be optional. #163: Make is clear that BlockingInteractionResponse includes everything InteractionResponse does. => Two possibilities: 1. Additional verbiage in the text. 2. Explicitly include an InteractionResponse in an UpdateResponse => If we want to make this more explicit, I would favor #2. #162: OperationNotSupportedOnThisNavigationalStateFault Needed Description: Some Producers may use only performInteraction, or only performBlockingInteraction, or just use getMarkup. Or maybe some Producers support performInteraction only on some navstates, performBlockingInteraction on others, and getMarkup on yet others. There is no way to return a fault that indicates this => Use case for when the entity-supplied navState can't be used with the entity-declared operation? #158: Length of sessionHandle (rename to sessionState and remove length?) => This is the one handle whose size people most wanted to restrict at the Nov F2F #158: Length of entityInstanceID (rename consumerEntityHandle and impose length?) => I would not rename this a handle as it is not a remote reference. Do we want to impose the same length restrictions on it as on handles? I think this is likely a good idea as the Producer (or entity) is likely to use this as a key. #???: navigationalState in InteractionResponse? (question Gil raised) This field should not be included in InteractionResponse as: 1. this response is returned by performInteraction. 2. Some consumers may want to redirect to a new Consumer URL based on this navigationalState. 3. performInteraction can be called by the Consumer after returning markup to the end user, and thus it may be too late to redirect => performInteraction carries the semantics that the entity does not require the Consumer to block ... the Consumer may choose to block streaming output to the client for other reasons (such as the redirect mentioned), but that is independent of the entity. I think it is important that the logical action implied by a call to performInteraction be able to modify navigationalState ... otherwise developers will find this call rarely useful and will always code urls to be BlockingActions. #165: The Consumer should not strip the namespace prefix from form parameters Description: "Quoting from the spec: ""If namespace encoding is used for form parameters or other data the entity receives as in markupParams, then the Consumer MUST strip the namespace prefix from the parameter names before passing them to the Producer"". believe the Consumer should not do this for two reasons: 1. It now means that the Consumer has to understand the uploadData and recognize one of the mime types, specifically application/x-www-form-urlencoded. This is definitely not generic. 2. The Producer will anyway have to understand namespace prefixing, including using it in JavaScript client code, so its not that big of a chore for the Producer to do this (for example, by adding another form parameter which includes the prefix code)." => Not sure when this came in or its rationale .... #166:Remove the section on load balancing Description: Remove this section, or at least move it to the introduction. The requiresInitCookie, although motivated by load balancing concerns, may be used for other purposes, and thus should not be tied anymore to load balancing. Load-balancing considerations are definitely OK in a non-normative introduction, but not in the normative spec #167:userContextID should not be a required field Description: The Consumer may not "have" a user, and thus the userContextID should be optional #168:Make wsrp-navigationalState required Description: "In section 9.2.1.2 it is written ""If this parameter is missing, the Consumer MUST send the current navigational state"". This effectively forces a Consumer that stores the navigationState in the URL (for example, a stateless Consumer) to also store the previous navState on the URL so that it can be used if the Producer did not send a navState! propose changing it to: ""the Producer SHOULD send the navState to the Producer. If this parameter is missing, then the new navState is an empty string.""" 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] | [Elist Home]
Powered by eList eXpress LLC