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

Ouverte
  • Quelque chose ne va pas ?
#343 6 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

@ManishS6 y travaille déjà.

Depuis le 4/10/2024.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
À l'abandon
Stack technique
java
Domaine
api

Piste de recherche

Commencez par lire Cloudinary.loadStrategies(), Cloudinary.class et Configuration.class afin de comprendre le chargement actuel des stratégies et la configuration basée sur Map. Examinez comment les stratégies Apache, OkHttp, Jetty et Asynch sont sélectionnées et comment la configuration parvient au constructeur. Done devrait fournir une manière définie et documentée permettant aux consommateurs de sélectionner des clients HTTP et de les configurer sans Map opaque.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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<AbstractApiStrategy>. 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.

Langage dominant
Java
Étoiles
176
Forks
113
Merge moyen
9 j 20 h
PR mergées (30 j)
2

Préparer son environnement

  • Aucun Dockerfile ni fichier Docker Compose
  • Propose un modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de cloudinary/cloudinary_java

Toutes les issues de cloudinary/cloudinary_java

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.