On 03/30/2011 02:23 PM, Nathan Kinder wrote:
> On 03/30/2011 08:03 AM, Dmitri Pal wrote:
>> On 03/30/2011 10:39 AM, Nathan Kinder wrote:
>>> On 03/30/2011 06:00 AM, Dmitri Pal wrote:
>>>> Hello,
>>>>
>>>> Please find the design for the auto membership plugin:
>>>> https://fedorahosted.org/freeipa/ticket/753
>>>> Here: http://directory.fedoraproject.org/wiki/Auto_Membership_Design
>>>>
>>>> I have some comments and questions:
>>>> 1) Is the AND functionality for inclusion criteria required?
>>> I'm not sure.  Is there a use case for it?
>>>> 2) How the attributes are escaped? Do they need to? Probably there
>>>> will
>>>> be cases when they should be escaped
>>> Where exactly are you thinking that they need to be escaped? Why do
>>> you think they might need to be escaped?
>> Wild cards and regular expression might have special symbols like "="
>> "\" slashes etc.
>> If we decode to support AND it would probably be solved by concatenating
>> multiple attr=regex pairs in one attribute. I am concerned it will be a
>> challenge to parse.
> We use libpcre elsewhere in 389 to allow regular expressions to be
> used.  We actually have a public regular expression API within SLAPI
> (the slapi_re_* functions).  We would leverage these functions in this
> plug-in.  The SASL mapping code already uses these for something
> similar, so there is not a new problem to solve here.

I am not worried about you, I am worried that we will have to parse it
in the python code and may be Javascript in ­CLI.
Hope we can create an abstraction on the management plugin side that
will do the trick and hide it from actual UI and client part of CLI.
But anyways this means two different parsers - internal in the DS plugin
and external in the management plugin.


>>>> 3) Parsing pairs in the value as a bit of overhead. I wonder if
>>>> there is
>>>> any way to avoid it?
>>> Do you mean parsing the pair contained in the "autoMemberGroupingAttr"
>>> attribute in the config definition entry?  This will only be parsed
>>> when the definition entry is loaded at startup or when it is
>>> modified.  It would be stored in a different form that is more
>>> efficient to use when we actually need to perform auto membership
>>> operations.
>> Yes I am concerned about parsing pairs for the purposes of the modify
>> operation in CLI/UI.
> This is only done when loading the config, so it's a one-time penalty
> at startup or when the config is modified (which should be fairly
> rare).  I wouldn't worry about this.
>>> -NGK
>>>> 4) I have concerns about the UI and CLI, do you see any good ways to
>>>> mange such entries?
>>>>
>>> _______________________________________________
>>> Freeipa-users mailing list
>>> Freeipa-users@redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>
>>>
>>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


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



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

Reply via email to