[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [Fwd: [wsrp-wsia] re: Issues for 10/17]
FYI .. the title should have read "Issues for 10/17". Sorry for any confusion. -Mike-
--- Begin Message ---
- From: Michael Freedman <Michael.Freedman@oracle.com>
- To: wsrp-wsia <wsrp-wsia@lists.oasis-open.org>
- Date: Tue, 15 Oct 2002 15:53:02 -0700
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>--- End Message ---
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC