RE: [provision] Two minor problems...

["Jeff Bohren" <jbohren@opennetwork.com>]

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