Simo Sorce wrote:
> On Fri, 15 Oct 2010 14:12:22 -0400
> Dmitri Pal <d...@redhat.com> wrote:
>   
>> Simo Sorce wrote:
>>     
>
>   
>>> I'd go for the last one, may be ugly, but does not undo anything
>>> that already works and has the effect of simplifying the UI which
>>> is what you are after right now. Of course that also means the UI
>>> will have to cope (maybe disabling editing) with any entry that has
>>> been nested through the CLI or over LDAP directly.
>>>   
>>>       
>> This is where ugliness comes to play.
>>
>>     
>>> This is assuming the UI work would really be more complex. We have
>>> nesting to support for other things already so I am not sure it
>>> would really be substantially less work to do the same thing
>>> elsewhere, I bet a lot of code could simply be reused.
>>>
>>>   
>>>       
>> It is not that simple.
>>     
> [..]
>
> Ok, then I guess removing the possibility is simpler.
> Though reading the schema definition I wonder one thing. Why did you
> make these objectclasses derive from nestedGroup ?
> I would have expected them to be "SUP groupOfNames" and just have the
> clients add nestedGroup if they wished to enable them to be nested.
> Of course this means nestedGroup needs to be AUXILIARY and not
> STRUCTURAL.
> Is there any reason to make nestedGroup forcibly structural ?
> Having it auxiliary means we can later add it to objects not currently
> nestable, although this may also be seen as a liability.
>
> The problem is that if we do not then we are stuck with whatever we
> decide I think. Changing a fundamental objectclass once we reach 2.0 is
> one of things we tentatively forbid ourselves to do in the name of
> compatibility.
>
>   

I disagree. We can move from group of names to nested group at any
moment in future by just doing schema change not even requiring full
dump and load.
We are not locked on it. Nested group is just an alias. Adding "MAY
memberOf" will do a trick or we can change it to nestedGroup explicitly.

I do not see us generally bound to this specific schema. We are bound to
be able to migrate from this schema and not loose functionality. This is
definitely the case here.
 
> Simo.
>
>   


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to