> On 23 Mar 2020, at 12:52, William Brown <wbrown@suse.de> wrote:
>
>
>
>> On 21 Mar 2020, at 01:37, thierry bordaz <tbordaz@redhat.com> wrote:
>>
>> Hi William,
>>
>> I only have a vague knowledge of syntaxes/MR.
>>
>> Each syntax is a plugin. Its init function registers for a given set of OIDs the matching rules (compare, order, substring) than handle that syntax (calls slapi_matchingrule_register).
>> There is a special collation plugin that does the same for supported language.
>> So a entryUUID syntax should define its matching rules callbacks and register them for supported OID.
>>
>> The MR are called during filter evaluation, both at candidate list built and at filter match.
>> On write path, they are called to generate the index keys.
>>
>> I think there is a slight difference between syntaxes plugins and collation plugin in the way they are selected to apply for a given attribute.
>> syntaxes provide the set of supported OIDs while for collation you need to call the index to know if it supports the OID.
>>
>> All of this are general ideas around syntax/MR and I think they are quite correct.
>
> AHhhh, some of these things have helped me make sense of some of the plugin handle names and such. Thank you! I might put in a work-in-progress PR later of my work on entryuuid. :)
>
> Thanks Thierry!
As a follow up, thanks for the advice - I can now register a stub syntax plugin into the server (in rust) :D
So I'll be doing more to get this working in the coming days. Thanks again for your advice!
>
>
>
>>
>> best regards
>> thierry
>>
>>
>> On 3/20/20 4:37 AM, William Brown wrote:
>>> Hi there,
>>>
>>> I'm looking to add the syntaxes to handle entryUUID properly, because they have a different format to nsUniqueId. Thinking that I need to look at the plugins under ldap/servers/plugins/syntaxes/, but it would be good to have some extra insight about the plugin hooks. Should I look at the old plugin guide? Or is there some extra info I can get from somewhere?
>>>
>>> Thanks!
>>>
>>> —
>>> Sincerely,
>>>
>>> William Brown
>>>
>>> Senior Software Engineer, 389 Directory Server
>>> SUSE Labs
>>> _______________________________________________
>>> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
>>> To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
>>> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>>
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> _______________________________________________
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
No comments:
Post a Comment