[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] Two minor problems...
I would agree with that except for the case of asynchronous searches. If we are going to support asynchronous searches we need a way for the requestor to get the status of the search request without getting the search results. We could go back to the original method, but make the "respond with flag" on the status request to default to respond with a full response (i.e. status and data). For search request status, the request could set this flag to status only. Also to simplify this, I would propose that the status response never return result data until the original request is complete. In other words, there will never be a partial results set returned. That is something that might be usefull for searches, but probably adds too much complexity. Jeff Bohren OpenNetwork Technologies -----Original Message----- From: Cohen, Doron [mailto:Doron_Cohen@bmc.com] Sent: Mon 3/24/2003 10:07 AM To: Jeff Bohren; provision@lists.oasis-open.org Cc: Subject: RE: [provision] Two minor problems... 1) I agree we should have a way to return the responses of the asynchronous request as part of the StatusRequest, but I really did not like the original use of returnType that was aimed to select between Status or Response . I would prefer to have an optional response element as part of the StatusResponse without the need to select in StatusRequest whether I choose one or the other . Doron Cohen BMC Software -----Original Message----- From: Jeff Bohren [mailto:jbohren@opennetwork.com] Sent: Monday, March 24, 2003 3:36 PM To: provision@lists.oasis-open.org Subject: [provision] Two minor problems... While working on the bindings document I discovered two minor problems we should address. 1) The status request originally had a mechanism for asking for the results of the asynchronous request to be returned in addition to the status. This was removed by a motion at a previous conference call. Without this feature you can not support asynchronous add request that return the generated identity (use case 2). You also can not support asynchronous extended requests that return data. You also can not support any asynchronous request that returns operational attributes. And finally, you can not support asynchronous searches. To fix this I would like to make a motion at today's meeting to restore the original functionality. The specific motion would be: Motion to add the optional capability to return the results of a request in the status response message. 2) The File Binding does not have a good way to handle bulk import and export of accounts and other provisioned data. If we added a simple data envelop element to core, then this feature could be supported. This would allow a standalone file to be defined that would specify and other provisioned data. The specific motion would be: Motion to add an element that could hold an arbitrary list of provisioning data for use in the File Binding. Jeff Bohren OpenNetwork Technologies
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]