cloudinary / cloudinary/cloudinary_java

Make usage of http clients (apache, OkHttp, Jetty, Asynch) easier

Đang mở
#343 6 bình luận 0 reaction 0 người được giao Xem trên GitHub
Ngôn ngữ chính
Java
Star
175
Fork
113
Chỉ số merge pull request
Không có pull request nào được merge trong 30 ngày

Mô tả

## Feature request for Cloudinary Java SDK

General idea: making the settings of http client library to be used easier for consumers of the SDK,
by enabling configuration via `new Cloudinary(...)` constructor.

## Explain your use case
I want to use plain java http client, instead of Apache one.

## Describe the problem you’re trying to solve
In `Cloudinary.loadStrategies()` there's a fixed list of strings with classnames, which a consumer of the SDK can't change.
This means even if I provide my own strategy, this will not loaded and I still being forced to add dependency for apache http.
(hint: technically: when the class `om.cloudinary.http5.ApiStrategy` is not found, an `UnknownError` is thrown, which is bad)

Also this brings me to another point: the constructor of Cloudinary should better accept Configuration object, instead of `Map config`. It's very annoying for me as an SDK user, to provide a Map with configs.
I get no auto-completion on Maps and must find details in either source code or documentation (which is just cumbersome).
So I don't know immediately what config options are available, that I could e.g. provide HTTP proxy address.

(Sorry, if I mix two problems here ... I came to these two, when I thought about a solution proposal, below)

## Do you have a proposed solution?
YES.
The constructor of Cloudinary.class (or better the Configuration.class) could have some new field `apiStrategy` of type `class`. And another one for the UploadStrategy.
Then, the loadStragies() method will not load by name (which can contain typos), but rather by class(type) directly.

On the second problem, adding a new (overloaded) constructor to Cloudinary is easy to add, but that's not sufficient.
Ideally, the Configuration class will provide a convenient Builder function, so users of the SDK are better guided,
and plausibility checks can easier be implemented.

I'm happy to provide a PR, if this resonates with you.

Hướng dẫn đóng góp

Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này

Đánh giá

Issue này chưa được đánh giá.

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.