Re: [provision] Non-batchable operations.

[Gary P Cole <Gary.P.Cole@Sun.COM>]

I think what Jeff says is reasonable.  Batch-being-batchable gives me a 
little bit of heartburn, but I'm not sure how much I care.  (In addition 
to the possibility that a batch might imply atomicity, I *suppose* that 
you could achieve some interesting failure semantics by nesting batches 
with different settings for 'onError' and 'processingMode'.)  However, I 
will note that in SPML1.0 the batch request was not itself batchable.  
Are we *sure* we want to support nested batches?

I'm okay with bulk operations being batchable.  There is no scale issue, 
and I see no logical issue.

Jeff Bohren wrote:

> 
>1, 3, 4, 5, 6 all seem reasonable. 
> 
>I would not want to restrict batch to not being batchable. This is for the case where batch is being used to provide atomic semantics (assuming the service provides such support). A batch of batches would be an atomic transaction composed of atomic transactions. I doubt that this would really ever be used, but I also don't see a reason to disallow it either.
> 
>The bulk operations should absolutely be batchable. For instance if there is a need to perform the same bulk operation to two different targets, it would make sense to batch them.
> 
>Jeff B.
>
>	-----Original Message----- 
>	From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
>	Sent: Thu 2/17/2005 9:44 AM 
>	To: PSTC 
>	Cc: 
>	Subject: Re: [provision] Non-batchable operations.
>	
>	
>
>	I agree that this is the real question, so I'll repeat the original
>	content (since it may have been lost or buried in subsequent replies in
>	this thread).
>	
>	It seems clear to me that:
>	1) 'listTargets' is not batchable
>	   (for the same "bootstrapping" reasons that it is synchronous).
>	2) 'batch' is not batchable
>	   (it would be a mess to nest these).
>	3) 'search' is not batchable
>	   (the batch response could become far too large).
>	4) 'iterate' is not batchable
>	   (for the same reasons that it must be synchronous)
>	
>	I don't see why Async Capability operations would be batchable
>	(since they must be synchronous and batch is usually async):
>	5) 'cancel' should not be batchable
>	   (seems weird to batch a cancel request with other requests;
>	    the batch would have to be synchronous)
>	6) 'status' should not be batchable
>	   (seems weird to batch a status request with other requests;
>	    the batch would have to be synchronous)
>	
>	Finally, I'm not sure that Bulk Capability operations should be batchable
>	(but I cannot really say that this would cause a problem):
>	7) 'bulkModify' ?
>	8) 'bulkDelete' ?
>	
>	Everything else (add, lookup, modify, delete, setPassword,
>	expirePassword, resetPassword, validatePassword) seems okay to be
>	batchable.
>	
>	I lean toward normatively specifying at least those that are NOT
>	batchable. For example, to batch a listTargets request is a logical
>	error.  To batch a batch request seems a very bad idea--this way lies
>	madness.
>	
>	Jeff Bohren wrote:
>	
>	>So now the real question is what should normatively specified as batchable. I really don't see any value in normatively calling out certain verbs and declaring them batchable. I would lean towards leaving this unspecified.
>	>
>	>
>	
>	
>	
>	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.
>	
>	
>
>  
>