Skip to content
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

RfE: Provide a simplified Media upload api #62

Open
pilhuhn opened this issue Dec 31, 2022 · 4 comments
Open

RfE: Provide a simplified Media upload api #62

pilhuhn opened this issue Dec 31, 2022 · 4 comments
Labels
breaking Incompatible with previous versions code quality Everything related to code quality

Comments

@pilhuhn
Copy link

pilhuhn commented Dec 31, 2022

The current api for media upload is complicated and requires multiple steps, which are not super well documented (already in the original mastodon4j code).
Provide a simple Media.upload() method / builder, that 'asks' for the required parts and does the magic of MultipartBody.Part handling under the covers. One option would be some fromFile() and/or fromResource() / fromUrl() builder methods to upload the actual content.

@andregasser andregasser added the code quality Everything related to code quality label Jan 2, 2023
@andregasser andregasser added the breaking Incompatible with previous versions label Jan 3, 2023
@bocops
Copy link
Collaborator

bocops commented Jan 5, 2023

@pilhuhn Would a method with the signature postMedia(file: java.io.File, mediaType: String) work for you as an intermediate result?

That would bring the handling of MultipartBody.Part into the method and hide it from library users. It would not yet relieve them from some file handling (and mediaType detection), but I'm not sure if Media.kt itself would be the best place for such functionality or if we shouldn't offer that separately.

bocops added a commit to bocops/bigbone that referenced this issue Jan 5, 2023
Changes Media.postMedia() to accept a File and a media type String as parameters, then builds the necessary okhttp3.MultipartBody.Part itself instead of exposing this.

A more extensive Builder was suggested in andregasser#62, but I think that would need to live elsewhere, not directly in one of our method classes.
@pilhuhn
Copy link
Author

pilhuhn commented Jan 5, 2023

@bocops Absolutely.

bocops added a commit to bocops/bigbone that referenced this issue Jan 5, 2023
Changes Media.postMedia() to accept a File and a media type String as parameters, then builds the necessary okhttp3.MultipartBody.Part itself instead of exposing this.

A more extensive Builder was suggested in andregasser#62, but I think that would need to live elsewhere, not directly in one of our method classes.
@bocops
Copy link
Collaborator

bocops commented Jan 5, 2023

@pilhuhn Great, that change should be part of the next snapshot.

@andregasser Should we have a general discussion about service functionality such as the Builder with different sources for file data suggested by pilhuhn? On the one hand, I can definitely see how that would make life easier for library users, but on the other hand, it is not strictly "Mastodon client" functionality but a whole new layer on top of it. Perhaps that is something for a later date, after core functionality works as expected?

@andregasser
Copy link
Owner

Sure, let's have a discussion on how we could simplify the media upload API further. Feel free to open a new discussion thread. For the moment I think the File-based approach is sufficient to be released as part of 2.0.0. I am happy to see that okhttp3 stuff is no longer exposed to the user that way.

As soon as we know how to build the new MediaUpload API, we can open an issue and start implementing it.

Hope, that sounds like a plan 🙂

Btw: I have just published an updated snapshot, so @pilhuhn should be able to use the new API now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking Incompatible with previous versions code quality Everything related to code quality
Projects
None yet
Development

No branches or pull requests

3 participants