[security-dev] IDM:: API Change question - feedback requested

Anil Saldhana Anil.Saldhana at redhat.com
Thu Nov 29 11:02:59 EST 2012


Tough issue. :)  We are getting into subjective world.   The question is 
what would be intuitive to a developer who uses IDM
and probably JPA.

On 11/29/2012 09:22 AM, Marius Bogoevici wrote:
> persist() has the added meaning of update()
>
> On 2012-11-29, at 9:16 AM, Pete Muir <pmuir at redhat.com> wrote:
>
>> I prefer add() to persist(), IMO it's more obvious.
>>
>> On 29 Nov 2012, at 01:24, Shane Bryzak wrote:
>>
>>> Just to add to this, the idea is to essentially mimic the JPA API, which
>>> provides persist(), merge() and remove() methods.  What we are proposing
>>> is a slight variation of this, as follows:
>>>
>>> public interface IdentityManager {
>>>
>>>     // snip other methods
>>>
>>>     /**
>>>      * Persists the specified IdentityType
>>>      */
>>>     void persist(IdentityType identityType);
>>>
>>>     /**
>>>      * Updates the persisted state of the specified IdentityType, with
>>> the exception of the id and name for Groups, and name for Roles
>>>      */
>>>     void update(IdentityType identityType);
>>>
>>>     /**
>>>      * Removes the specified IdentityType
>>>      */
>>>     void remove(IdentityType identityType);
>>> }
>>>
>>> Just a reminder, that IdentityType is the super-type for User, Group and
>>> Role so these methods can be used for any of these. This would simplify
>>> the IdentityManager API considerably (replacing an existing 7 methods
>>> with just 3) while providing more functionality (currently the API
>>> doesn't allow Roles or Groups to be updated).
>>>
>>> On 11/29/2012 10:40 AM, Anil Saldhana wrote:
>>>> Hi all,
>>>>    Shane, Pedro and I have been discussing the following use case and
>>>> agree on method name change. Shane suggested the list due to it being an
>>>> API change.
>>>>
>>>> The developer can ask the Identity Manager to create an instance of
>>>> User/Role/Group  (IdentityType). This use case is pretty clear.
>>>>
>>>> Now if the developer wants to create his own instances of U/R/G as:
>>>>
>>>> User user = new SimpleUser("userA");
>>>>
>>>> Now he needs to persist this to the store.
>>>>
>>>> The current API call would be:
>>>>
>>>> User storeUser = identityManager.createUser(user)
>>>>
>>>> We feel this is not as intuitive as:
>>>>
>>>> User storeUser = identityManager.persist(user)
>>>>
>>>> Objections to this API change?
>>>>
>>>> Regards,
>>>> Anil


More information about the security-dev mailing list