-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The way to use this library for different Aliyun OSS endpoints #78
Comments
Hi, @c4710n, thanks for your suggestion. I agree the global configuration is something we need to change. Your solution sounds perfect to me. It would be great if you can implement this. I'll be more than happy and grateful to accept a PR. |
@ug0. I'm very happy that you like my idea. ;-) The first step I would like to do is to I notice that this repo already has a
It's ok to use it. But, before using it, I want to confirm your preference on line_length, the default 98 or a customized one?
|
The default is fine. |
Got it. I have created a PR which formats the existing code. - #79 Then, I'll work toward the goal. |
#79 has been merged. |
Thanks
Hi, @ug0, thanks for implementing this great library.
The problem
Recently, I have to operate on different Aliyun OSS endpoints.
But,
:aliyun_oss
is usingApplication.get_env/2
to getting the global configurations, which makes it impossible to setup:aliyun_oss
for different Aliyun OSS endpoints. For example, inconfig/runtime.exs
:Some official guidelines
I searched a lot about how to solve this problem. And I found, in the official docs, there is some guidelines about the design of a library:
Don't misunderstand me, I'm not saying you are doing it wrong. It just doesn't meet the needs at the moment, so maybe we need to make some changes.
A possible solution
local configuration provided as a function argument
If we don't use global configuration any more, what should we use? Local configuration provided as a function argument.
Take
Aliyun.Oss.Bucket.list_buckets/1
as an example, the current function signature is:After adding a local config, it becomes:
improve the type of config
It's bad to use a random map as configuration, we can do it better - reuse existing
Aliyun.Oss.Config
and use it provide a%Config{}
struct, such as:And the function signature becomes:
When we want to call this API, we do this:
Is the possible solution works?
Suppose that I have 2 Aliyun OSS endpoints, and I want to operate on them with two different modules. Then I can implement something like this:
These two modules are using different configurations as expected.
"Wait. Does that means users have to map every API?"
Users don't have to every API, but only the API they need.
In real apps, it's rare that all the API provided by
:aliyun_oss
are required. In general, only a few API are required."Oh, Good. But what should I do?"
The things that need to be done are:
But I'm not going to let you do it, after all you've done all of this library.
If you like my ideas and trust me, I can do this.
Last
Any ideas? Please let me know.
The text was updated successfully, but these errors were encountered: