OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: FW: [provision] CA will be participating in the SPML v2Interoperability Event - A few question (Looking for Responses) are inline inthe message


Sodhi, Gavenraj S wrote:

> *** Posting on behalf of CA Development Team** *
>
> Jeff,
>
> Thank you very much for answering my questions. I have to confess that 
> I haven’t read the specs carefully so in question 3 I did not think of 
> the situation where the Requestor is not allowed to provide a full 
> psoID in an Add Request. But things are much clearer now.
>
> As for question 5, I was asking if a bulk response can return the list 
> of PSO’s that WERE affected by the bulk operation, which is essential 
> for client-side auditing and monitoring. If the answer is ‘no’, then I 
> guess that we will just add a custom operation for this functionality.
>
We did consider allowing a bulk response to return data describing the 
affected objects, but decided against it. Returning data for each 
affected object would adversely affect performance and scalability. In 
some cases, such considerations might prevent a provider from supporting 
the bulk capability. (Several committee members expressed hesitation to 
support the search capability for these reasons.) The strongest 
argument, however, is that this behavior is not strictly necessary.

A bulkModify is a shorthand for search+modify. A bulkDelete is a 
shorthand for search+delete. Each operation represents an optimization 
that is possible when the requestor does not care about the list of 
objects affected.

When a requestor needs the list of affected objects (e.g., for 
client-side logging and monitoring), the requestor should issue a search 
operation and then modify or delete each item in the search result. This 
ensures that the list correctly corresponds to the set of objects 
modified or deleted. The set of objects modified or deleted will also be 
correct as of the point in time that the provider performed the search 
operation.

There is no need (in the strict sense) for a custom operation. However, 
the desirability of such a variant may justify defining it as part of a 
new capability.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]