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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

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


Subject: [Bug 250] New: update timeout for begin and setTimeout


http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=250

           Summary: update timeout for begin and setTimeout
           Product: WS-Context
           Version: 1.0
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Text and diagrams
        AssignedTo: ws-caf@lists.oasis-open.org
        ReportedBy: mark.little@arjuna.com
         QAContact: mark.little@arjuna.com


The gist of the "other issues" mentioned in this action starts from the following:

    Context
        expiresAt -- type 8601 / XML Schema dateTime
    begin()
        timeout -- seconds
    setTimeout() {default for future begin operations}
        timeout -- seconds

The text in the specification connects setTimeout() with begin() but is no
longer connected with the renamed element in Context.  I seem to remember the
only previous link between timeout in begin() and the old element in Context was
their identical names.  The inconsistency in types and semantics of the three
items above should generally be reduced.

begin() can be made immediately consistent with Context through changing its
parameter to have an identical type and name to that used in Context.  We should
also be explicit and state that Context.expiresAt is set directly from the new
expiresAt parameter of begin().

setTimeout() is a bit more difficult since a specific dateTime value is not a
very useful default for numerous future begin() calls.  I would recommend this
parameter keep its current name or be named defaultTimeout (just for clarity). 
We could keep the current type and describe how those seconds are added to the
service's notion of the current time to set the Context.expiresAt value in all
future begin() operations (until the next setTimeout() operation) without an
expiresAt parameter.  I would recommend going one step further and change this
parameter's datatype to be an 8601 / XML Schema duration.

Is this enough to write up separate issues for begin() and setTimeout() with the
second depending upon the first?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


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