> On 23 Mar 2020, at 12:52, William Brown <wbrown@xxxxxxx> wrote: > > > >> On 21 Mar 2020, at 01:37, thierry bordaz <tbordaz@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx >>> To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx >>> 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@xxxxxxxxxxxxxxxxxxxxxxx >> > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server > SUSE Labs > _______________________________________________ > 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
