[MONGOCRYPT-111] libmongocrypt: create individual opts setters Created: 29/Mar/19 Updated: 28/Oct/23 Resolved: 01/Apr/19 |
|
| Status: | Closed |
| Project: | Libmongocrypt |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Kevin Albertson | Assignee: | Kevin Albertson |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Epic Link: | Build libmongocrypt library |
| Description |
|
mongocrypt_opts_t was designed with future-proofing the API and was inspired by curl. Options are identified by an enum value and set with a void*. It's documented here. However, now I think this isn't the appropriate API for libmongocrypt. Type erasing the value seems annoying in wrappers. mongocrypt_opts_set_opt accepts generic values by taking a void* value. But wrappers often have to marshal out their native value into the appropriate C value. E.g. in Python, wrapping the mongocrypt_opts_set_opt directly would require Python code like:
So, that wrappers will likely either write individual functions for each option type, or have to do that type checking. This seems to goes against libmongocrypt's design goal of being easy to integrate. Additionally, mongocrypt_opts_set_opt does not return a status currently. It seems preferable to do option validation when the option is set instead of waiting until the mongocrypt_t is initialized. I propose we do away with mongocrypt_opts_t entirely and add individual option setters. Instead of:
We'll do:
The downside is that future options add more API functions. But as it is, we'd still need to add to the enum. Wrapping another function later doesn't seem significantly more difficult than wrapping a new enum value. |
| Comments |
| Comment by Githook User [ 01/Apr/19 ] |
|
Author: {'name': 'Kevin Albertson', 'username': 'kevinAlbs', 'email': 'kevin.albertson@mongodb.com'}Message: |