[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-core-dev] Request for clarification on status
|
The status codes are not API at this time. In many cases it would be
impossible to specify the complete set of status codes returned from a
given method as the method may just be a front for some pluggable
implementation. We could have a more rigorous strategy where we require
implementors to return a specific set of status codes but this gets messy
where they need to extend this set.
Having said that, we are not particularly happy with this situation.
Currently no work is planned in this area.
Jeff
Greg_Adams@xxxxxxx
Sent by: To: platform-core-dev@xxxxxxxxxxx
platform-core-dev-admin@e cc:
clipse.org Subject: [platform-core-dev] Request for
clarification on status
12/09/2001 03:17 PM
Please respond to
platform-core-dev
I seek guidance from core on the following. I suspect others would
appreciate the clarification aswell. In this note I use the status code
/discussion from RFC 001 but this is a general issue not just RFC 001.
1) In the discussions for RFC 0001 the spec states:
"API methods do not formally guarantee what status codes will be returned
for a given error condition".
Thus doing a check IResourceStatus.CASE_VARIANT_EXISTS may subsequently
cause the code behave differently.
Note: It is ok to have actual values changing providing all tests such as
the one shown above work unchanged - but this did not seem to be what was
being implied by John Arthorne.
2) It was further clarified in the spec as:
"while the status code returned by a particular method are tecnically
fuzzy, we strive to avoid changing return status code without a very
compelling reason and sufficient advance notice" .
3) My Concern:
ISV's have been told either things are API or they aren't & they should
only use API and cannot rely on non-api. It seems dangerous/confusing to
clients to discuss a middle ground where we instruct ISV's they should be
able to rely on something not changing even though it's not API. The status
information above (see 1 & 2) appear to be of this flavour.
Does core view this as API (and as such subjected to the API rules stated
in the V2 plan), or is it not api and hence one should treat it as such
(i.e. avoid). While the intent in 2 is good, stating it API is stronger.
Not making the API statement means avoid it.
Thanks in advance.
/Greg
