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] | [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