[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ErrorCode#insufficientResources.
I haven't had any idea that I think is better than 'insufficientResources', but it is possible that I have a mental block. Could use some help from the list here. The original purpose of 'count' and 'totalCount' was to indicate that a search result was incomplete. Either the query selected more objects than the requestor specified in 'maxSelect' (formerly 'maxReturn'), or the query selected more objects than the provider was willing or able to handle. (Since a provider is expected to queue for subsequent iteration any object in the search result that the provider does not return in the original <searchResponse>, this imposes a significant resource burden on the provider. The provider may have fixed limits, or the limits may depend on conditions including currently outstanding requests, but it is always possible that the resource burden will be too great.) In such cases, Jeff and I proposed that the search operation should fail (rather than returning a 'count' smaller than 'totalCount'). Jeff believes that a totalCount may not always be available, and we both agreed that a failure was more explicit. I suggested error='insufficientResources' because this seems clearest to me. That is, it clearly describes the condition that 'count' and 'totalCount' were intended to communicate. Jeff points out that a number of other back-end failures are possible, but I believe that a provider *always* faces the possibility of back-end failures. (Perhaps we should add *another* value of ErrorCode that indicates (or wraps) a back-end failure?) In this case, however, we're talking about *limits* rather than back-end failures. So, how about some suggestions? - error='insufficientResources'? (Jeff thinks this is too specific and none of the client's business.) - error='exceedsLimit'? - error='exceedsProviderLimit'? Bohren, Jeffrey wrote: >The other issues are valid. I will try to fix them in the next rev. > >Jeff Bohren >BMC > >-----Original Message----- >From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] >Sent: Tue 6/14/2005 7:26 PM >To: provision@lists.oasis-open.org >Cc: >Subject: Re: [provision] Draft 22 of the SPML 2.0 XSDs... > > > >1) Okay, let's look for something in-between "insufficientResources" and >"requestAborted". ErrorCode#requestAborted is so generic that it could >subsume just about every other value of ErrorCode we have defined. (In >a way, it's more like status='failure'. RequestAborted due to >unsupportedExecutionMode, RequestAborted due to invalidContainment, >RequestAborted due to unsupportedSelectionType....) > >Can anyone suggest a better name for this condition? > >2) Jeff, are the other issues valid? > >Bohren, Jeffrey wrote: > > > >>The error code ErrorCode#'requestAborted' is intended to be generic. The >>originally suggested error code 'insufficientResources' is too specific and >> >> > > > >>may not represent the actual error condition. For instance when a PSP is >>streaming back search results the search may be aborted by the underlying >>target. For example if the PSP is doing a long search on a backend LDAP >>server of RDBMS, the search could abort for a variety of reasons, none of >>which have anything to do with the PSP resources. >> >>Further it could be argued that the client has no reason to be concerned >>about the availability of resources on the PSP. >> >>I am open to other suggested names, but 'insufficientResources' seems >>unreasonable to me. >> >>Jeff Bohren >>BMC >> >>-----Original Message----- >>From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM <mailto:Gary.P.Cole@Sun.COM> >> >> >] > > >>Sent: Tuesday, June 14, 2005 4:53 PM >>To: Bohren, Jeffrey >>Cc: provision@lists.oasis-open.org >>Subject: Re: [provision] Draft 22 of the SPML 2.0 XSDs... >> >>CORE: >> >>ErrorCode#'requestAborted' should be changed to 'insufficientResources'. >>(Value 'requestAborted' is too generic--could apply to virtually any >>request failure.) >> >>Element <data> in PSOType must be optional (minOccurs=0) >>(This avoids empty <data> elements when returnData='identifier'.) >> >>SEARCH: >> >>Element "iterator" in CloseIteratorRequestType does not need >>"minOccurs=1 maxOccurs=1" >>(since this is the default cardinality). >> >>Top-level element "closeIteratorResponse" should be type='spml:ResponseType >> >> > > > >>(rather than type="spmlsearch:SearchResponseType"). >>A closeIteratorResponse should contain neither an <iterator> nor <pso> >>elements.) >> >>Bohren, Jeffrey wrote: >> >> >> >> >> >>>Draft 22 of the SPML 2.0 XSDs is attached. >>> >>> >>> >>> >>> >>>------------------------------------------------------------------------ >>> >>>*Jeff Bohren* >>> >>>13577 Feather Sound Drive, Suite 200, Clearwater, FL 33762 >>> >>>tel: 727.561.9500 x219 >>> >>>fax: 727.374.0171 >>> >>>Jeffrey_Bohren@bmc.com <mailto:Jeffrey_Bohren@bmc.com >>> >>> ><mailto:Jeffrey_Bohren@bmc.com> > > > >>>www.bmc.com <http://www.bmc.com/ <http://www.bmc.com/> > >>> >>> >>> >>> >>> >>> >>> >> >>--------------------------------------------------------------------- >>To unsubscribe from this mail list, you must leave the OASIS TC that >>generates this mail. You may a link to this group and all your TCs in >> >> >OASIS > > >>at: >>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> ><https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php> > > >>--------------------------------------------------------------------- >>To unsubscribe from this mail list, you must leave the OASIS TC that >>generates this mail. You may a link to this group and all your TCs in >> >> >OASIS > > >>at: >>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> ><https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php> > > >> >> >> >> > > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. You may a link to this group and all your TCs in OASIS > >at: >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php ><https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php> > > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. You may a link to this group and all your TCs in OASIS >at: >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]