[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] statusReturns.
|
I vote for A as I believe most requestors will not be able to use and
act upon partial results.
-----Original Message----- Has anybody thought any more about this issue? 1) Should the status operation by default return A) only "success", "failure" or
"pending"? B) A, plus any (possibly partial) results/output/content? Option A is lightweight (but is also perhaps a little
"pessimistic"). Option A is better if most requestors poll until an operation is complete and then (possibly) call once more for output. Option B is more expensive (e.g., in terms of network bandwidth). Option B is better if most requestors are so interested in the output
of operations that they are willing to process even partial results. I can accept either approach as long as the protocol exposes an option (such as 'statusOnly' or 'includeOutput') that controls this behavior.
Offhand, however, I prefer option A: - Most requestors will want to know whether a requested operation has completed. - Few requestors will need the output of a requested operation. (e.g., the <pso> that is returned by an 'add' or the PSO-ID
that is returned by a 'modify'). - Of those requestors that need the output of a requested operation, only a small percentage will want to process partial results (and to
re-process them, skipping over ones they've already processed, each time they call 'status'). gpc Gary P Cole wrote: > Jeff, > > Your suggestion of 'statusOnly' is an improvement on what we
currently > have, but I think we need to take this a little bit further. > > 1) It appears to me that SPML 1.0 specified (what we would now
call) > 'statusOnly' as the default so that a requestor could poll until
an > operation was complete and *then* request the output (or
"results"). > If we change this so that the 'status' operation returns output
(or > "results") by default, then (by default) each poll would
transmit data > (at least partially) redundant with (that of) the previous poll. > > 2) Even if we adopt the 'statusOnly' approach, I still need a term
I > can use to describe the output (or "results") of a
requested operation. > I currently use the term "output" in the draft
specification because I > found the distinction between "result" and
"results" too confusing. - > StatusReturnsType#status actually requests the "result"
attribute > (which is a value of type ResultCode). Even with your suggestion,
> 'statusOnly' actually requests the "result" attribute. > - StatusReturnsType#result actually requests the *output* of the > operation (which is nowhere formally described, except perhaps in
the > context of specific extensions of SpmlResponseType). > > I came up with the term "output" because
"results" was simply too > close to "result". What about using the term
"content"? > > 3) I think that the boolean option should request whichever
behavior > is NOT the default. > > If returning results/output/content should be the default, then I
like > your suggestion: > > <attribute name='statusOnly' type='xsd:boolean"
use="optional" > default="false"/> > > If returning only status/result should be the default, then how
about > > <attribute name='includeContent' type='xsd:boolean"
use="optional" > default="false"/> > > > gpc > > Jeff Bohren wrote: > >> IS this is confusing we should change it. I'm not thrilled
with "output" >> since this is a term we have not used yet. I would prefer to
keep it in >> terms that we already use. I also think the option of
returning the >> status and the resulting data should be the default. How
about: >> >> <attribute name='statusOnly' type='xsd:boolean"
use="optional" >> default="false"/> >> >> Jeff Bohren >> Product Architect >> OpenNetwork Technologies, Inc >> >> Try the industry's only 100% .NET-enabled identity management
software. >> Download your free copy of Universal IdP Standard Edition
today. Go to >> www.opennetwork.com/eval. >> >> >> >> -----Original Message----- >> From: Darran Rolls [mailto:Darran.Rolls@sun.com] Sent: Friday,
>> November 19, 2004 1:45 AM >> To: Gary P Cole >> Cc: Jeff Bohren; PSTC >> Subject: Re: [provision] statusReturns. >> >> I had trouble with this in 1.0 so i agree with (1); can't
answer (2) and >> >> your (3) makes good sense to me... >> >> Darran >> >> Gary P Cole wrote: >> >> >> >>> The 'status' operation can return either 1) the current
state of the >>> target operation (which is executing asynchronously) or 2)
any results >>> >> >> >> >> >>> of the target operation. The optional 'statusReturns'
attribute of >>> the StatusRequestType indicates whether the requestor
wants the >>> provider to return #1 or #2 above. The value of
"statusReturns" must >>> >> >> >> >> >>> be either 'status' or 'result'. >>> >>> Have I stated it correctly up to this point? If not,
please correct >>> me. If so, hold on, because this is where I think it gets
weird. >>> >>> If the statusRequest#statusReturns='status', then the
provider >>> actually returns (in the SpmlResponse that is nested as >>> statusResponse#currentResponse) one of >>> {'success'||'failure'||'pending'}. In other words, asking
for >>> 'status' gets you "result". >>> If the statusRequest#statusReturns='result', then the
provider >>> actually returns (in the SpmlResponse that is nested as >>> statusResponse#currentResponse) any output thus far
produced by the >>> target operation . In other words, asking for 'result'
gets you >>> >> >> output. >> >> >>> 1) Am I the only one who finds this confusing? >>> >>> 2) Doesn't status always have to return the
"result" attribute (in the >>> >> >> >> >> >>> SpmlResponse that is nested as
statusResponse#currentResponse) since >>> the "result" attribute is required? >>> >>> 3) Wouldn't it be simpler to have an optional attribute
that asks >>> the provider to return output? >>> Couldn't we replace 'statusReturns' with something like: >>> <attribute name='returnOutput'
type='xsd:boolean" use="optional" >>> default="false"/> >>> >>> gpc >>> >>> >>> To unsubscribe from this mailing list (and be removed from
the >>> roster of the OASIS TC), go to >>> >> >>
http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_wor >> kgroup.php. >> >>> >> >> >> To unsubscribe from this mailing list (and be removed from the
roster of >> the OASIS TC), go to >>
http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_wor >> kgroup.php. >> >> >> To unsubscribe from this mailing list (and be removed from the
roster >> of the OASIS TC), go to >> http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgroup.php.
>> >> >> >> > > To unsubscribe from this mailing list (and be removed from the roster
of the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgroup.php. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]