[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] Asynchronous requests.
Gary, I believe you may want to go async for many operation, even if not batch as the requestor as no way to predict how long the operation would take and opting for async. I would tend to agree that there is no point in status or cancel operations. Doron Doron Doron Cohen Chief Architect, Identity Management BU BMC Software Email: doron_cohen@bmc.com -----Original Message----- From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] Sent: Thursday, October 14, 2004 11:39 PM To: Jeff Bohren Cc: PSTC Subject: [provision] Asynchronous requests. Does it make sense to be able to issue a 'cancel' or a 'status' request asynchronously? I don't think so, since you'd have to keep track of the requestID of the cancel request in order to find out whether your cancel worked. Imagine keeping track of the requestID of a status request in order to find out the status of the status request. You see where I'm headed, right? It doesn't make much more sense to get the status of a status request than it would make to batch up batch requests. (We prevent the latter by specifying that BatchRequestType is not itself a BatchableRequestType.) Which operations would one want to execute asynchronously? - 'listTargets'? - 'cancel'? - 'status'? - 'lookup'? - 'search'? - an individual 'add'? - an individual 'modify'? - an individual 'delete'? Or does asynchronous execution make sense primarily for the 'batch' operation? 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_workgro up.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]