[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] re: Issues for 10/7
Mike, All, Below are the changes made to the issues list based upon Mike's email and the responses to it: #21 (initEnvironment verbiage) - left as tentatively resolved with the resolution now including the verbiage. #23 (clientParameters) - re-activated due to objections on resolution #31 (MINIMIZED state and markup) - left as tentatively resolved with the resolution now including more of the description of the resolution. As this is not in sync with JSR168, a new issue will probably be created on this out-of-syncness #34 (title to portal) - left as tentatively resolved, but with no resolution date. The resolution text states that we should wait for a rejection/confirmation from JSR168. #35 (URL encoding) - resolution moved back one week, per Mike's request. #43/#53/#82 (previous window state/mode) - re-activated. In the interest of sanity, I will remove these issues to "obsolete" mode and create _one_ issue that combines them all. (and in the darkness bind them? :->) #57 (refHandle unification) - re-activated. #74 (MAY or MUST releaseHandles) - re-activated. The two proposed resolutions are now in the "Description" part. #85 (sessionID expires MUST/MAY) - re-activated. The two proposed resolutions are now in the "Description" part. -----Original Message----- From: Michael Freedman [mailto:Michael.Freedman@oracle.com] Sent: Wed, October 16, 2002 00:53 To: wsrp-wsia Subject: [wsrp-wsia] re: Issues for 10/7 There are few issues this week that have been marked to move from tentative to resolved that I don't think are ready yet. Here are the comments for those issues: Issue #21: More verbiage for initEnvironment(). Though draft .7 adds more words to clarify this it still has a placeholder for defining the fault that indicates the inited environment has expired. Is there another issue open to address this? If not should we leave this issue open until the verbiage is complete? Issue #23: Adding clientParameters to getMarkup The resolution is too general. I suggest we tighten the definition/usage of clientParameters to merely mean the non-query string data that qualifies the request. I.e. the equivalent of what's carried in the http request headers (though because we are consumer mediated, it this information is client + consumer data). What I object to in the resolution is that it carries query string data. This is not information that portlets should encoding in their URLs. Finally, I think we should rename this field maybe to something like "qualifyingParameters". This field carries more than client headers. Issue #31: MINIMIZED state does not necessarily mean no markup. The resolution suggests that its in sync with JSR 168. However, the JSR has not synched with this resolution. This should remain open until we can resolve with the JSR. Issue #34: Do we want to define how an entity sends a title to the portal? The proposed solution doesn't match JSR semantics. We should keep this issue open until this is resolved [or open a new issue]. Issue #35: URL encoding I am still awaiting information from Sasha. I suspect this won't be "resolved" by Thursday. Can you move this back another week? Issue #43/#53/#82: previous window state/mode I disagree with the resolution. The resolution should be to remove entirely. Issue #57: unification of session handle and entity handle I think this should stay "tentative". The impacts of this decision are still being identified/discussed vis-a-vis cloneEntity/updating state etc. Issue #74: Should consumer MAY or MUST releasehandles I disagree with the proposed resolution. This isn't practical to implement/test for conformance. Rather we should just say something like "a consumer must not consider its registration with a producer dissolved until it successfully releases the registration. Consumer should deregister producers as soon as such registration no longer makes sense. Because of the distributed nature of such an operation, consumers should be prepared to detect releasehandle failures and to retry until successful or otherwise keep the current relationship open." Issue #85: sessionID expires MUST/MAY I disagree with the proposed resolution. MUST is too strong as a consumer needs to be free to manage its resources. Also, why can a a producer throw a fault indicating the entity session has expired? I thought that is only for initEnvironment? I suggest the following wording that excludes both the MUST and MAY words: "The Consumer uses this new value as the refHandle on subsequent invocations until either the Producer supplies another newRefHandle or the refHandleExpires duration indicates that the refHandle is no longer valid. Failure to pass this refHandle is analogous to prematurely terminating the session. Doing so may lead to unexpected or undefined user interactions. Consumers should only violate the above semantics under exceptional circumstances. Producers, however need to protect themselves and expect that an entity session may be "reset" on every request." -Mike- ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC