[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [provision] Non-batchable operations.
Participants in today's PSTC conference call agreed on a list of non-batchable operations *almost* as the chair had captured it. The sole change from the agenda item is that batches are not batchable. Participants agreed that the ability to nest batches is valuable when a batch implies an atomic transaction but that, since the batch capability does not imply transactional semantics, the ability to nest batches does not have enough value to justify the complexity that it implies. Gary Cole argued that a *transactional* batch should be a separate capability (even if it were syntactically similar to today's batch capability) because of the additional complexity required 1) to manage transactional semantics and 2) to undo specific operations. Rami Elron said that such a capability would need additional consideration and design. Darran Rolls therefore suggested that any such capability should be developed as a custom capability. This in turn spurred further discussion of an earlier suggestion that the PSTC should maintain a "registry" of capabilities in order to promote sharing and re-use. Gary P Cole wrote: > 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. >> >> >> >> >> >> > > > > 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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]