The map construction in opendal's C binding

[xyjixyjixyji]

In opendal, we use a HashMap<String, String> to support our init logic. But since HashMap is pretty complex to express and not a C native type, we need to be careful about it.

I currently have several ideas on how the C binding could construct the required HashMap, and really appreciate any suggestions or ideas on this topic.

1. Do not expose any HashMap thing to the user, the API will be like the following

opendal_operator_ptr opendal_operator_new(char *scheme, char **map_keys, char **map_values);

This API will reads keys and values and make a HashMap inside Rust code without exposing to users, but this will require user to make sure that the keys and values are in correct order. Moreover, the parameters are with less semantics.
e.g.

char keys[][] = {"k1", "k2"};
char values[][] = {"v1", "v2"};

is ok but

char keys[][] = {"k1", "k2"};
char values[][] = {"v2", "v1"};

is semantically not ok and often not detectable.

And

char keys[][] = {"k1", "k2", "k3"};
char values[][] = {"v1", "v2"};

is not grammarly ok.

2. Expose some of the HashMap by providing API like

opendal_map m = opendal_map_new(char **keys, char **values);

To control the behavior of opendal_map, we can expose limited API.
The disadvantage of this will be opendal C binding will be less native, since it relies on part of the Rust std, and the advantage will be it will allow for further operation like read and insert to it.

Again, I would like to hear everyone's opinions on the things above or any other possible implementation.

[Xuanwo]

We don't need to support map constrution for c binding. I expect to see something like AWS SDK CPP:

Aws::Client::ClientConfiguration clientConfig;
clientConfig.proxyHost = "localhost";
clientConfig.proxyPort = 1234;
clientConfig.proxyScheme = Aws::Http::Scheme::HTTPS;
Aws::S3::S3Client(clientConfig);

Since we have so many binding and services to support, maybe we should do some codegen work.

[xyjixyjixyji]

Also, different backends use different KVs, if we are using the AWS way, we accept params like opendal_operatior_config.

Every service will have their own builder like opendal_service_s3_builder. The hashmap thing is an easier way to build a S3Builder. And finally, we will use the builder to build the service.

So what about this way of API.

Builders:

opendal_builder_fs opendal_builder_fs_new(struct opendal_builder_fs_config);
opendal_builder_memory opendal_builder_memory_new(struct opendal_builder_memory_config);

Operators:

opendal_operator_ptr opendal_operator_new(char *scheme, void *builder);

And in runtime we cast the void* to what we want (the C way generics lol).

[Xuanwo]

Maybe we don't need to have both builder and config. Only keep builder like what we do for services LGTM.

Builders:

opendal_builder_fs opendal_builder_fs_new();
opendal_builder_fs_set_root(struct opendal_builder_fs *builder);

opendal_builder_memory opendal_builder_memory_new();

Operator:

opendal_operator_ptr opendal_operator_new(char *scheme, void *builder);

[xyjixyjixyji]

Maybe we don't need to have both builder and config. Only keep builder like what we do for services LGTM.

So you mean like

opendal_builder_fs builder = opendal_builder_fs_new()
   .root(char* root)
   .atomic_write_dir(char* root);

This seems not possible in C since it is not Object Oriented, no self is provided nor encapsulation.
If you are curious about this, you could take this to have a look.

Apart from the opendal_builder_fs_config way, the following is possible.

opendal_builder_fs opendal_builder_fs_new();
void opendal_builder_fs_root(opendal_builder_fs *builder);
void opendal_builder_fs_atomic_write_dir(opendal_builder_fs *builder);

I think both are acceptable, but the first one is more light weight.

[xyjixyjixyji]

That reply was before your edited comment, I got your point now, which way do you think is better, the config way or the function with pointer way.

[Xuanwo]

which way do you think is better, the config way or the function with pointer way.

Let's use the function with pointer for now.

[xyjixyjixyji]

Then the discussion could be closed.
We all agree on the builder pattern and function with pointer way of populating the builder.