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

🚀 Feature: Support for MINIO Object Storage #37

Open
2 tasks done
christyjacob4 opened this issue Mar 24, 2022 · 5 comments
Open
2 tasks done

🚀 Feature: Support for MINIO Object Storage #37

christyjacob4 opened this issue Mar 24, 2022 · 5 comments

Comments

@christyjacob4
Copy link
Contributor

🔖 Feature description

MinIO offers high-performance, S3 compatible object storage.
Native to Kubernetes, MinIO is the only object storage suite available on
every public cloud, every Kubernetes distribution, the private cloud and the
edge. MinIO is software-defined and is 100% open source under GNU AGPL v3.

https://min.io/

🎤 Pitch

Minio is a great candidate to add to the growing library of storage adapters

👀 Have you spent some time to check if this issue has been raised before?

  • I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

@SciBitHQ
Copy link

SciBitHQ commented Jan 18, 2023

Gents,

From the initial request appwrite/appwrite#3989 (comment)

To be honest, all the S3 drivers could have been made aliases of the parent class S3 by simply having the service URL as a parameter instead of hardcoding the URL into the code. The latter always being a bad idea to start with? The $bucket is never used again but to insert it into the hardcoded URL. It may in fact not even be required to have as parameter with some services if the bucket name is not part of the hostname or path or where a S3 service has either just one bucket or a completely different bespoke URL for each bucket? And so, if you had the URL as parameter, the bucket is superfluous in the constructor parameters?

There are thousands of S3 API compatible services online today, makes no sense to code a driver for each of them, when the only difference between them all is the initial URL. It makes complete sense to code a single driver for all of them. Making the URL a constructor parameter, would have solved @christyjacob4 's immediate problem to add MinIO support to appwrite. As it is, appwrite can also currently only consume a single bucket per appwrite instance & config restrictions. Would also have solved the SSL/problem, and would make the S3 driver class simply what the name implies, an S3 API compatible driver, instead of what it now is, that is, an Amazon service specific driver. That is, a driver coded to a standard instead of coded to a specific vendor.

A humble request to reconsider the current architecture path of the S3 driver, if at all possible.

@docimin
Copy link

docimin commented Jan 31, 2024

Gents,

From the initial request appwrite/appwrite#3989 (comment)

To be honest, all the S3 drivers could have been made aliases of the parent class S3 by simply having the service URL as a parameter instead of hardcoding the URL into the code. The latter always being a bad idea to start with? The $bucket is never used again but to insert it into the hardcoded URL. It may in fact not even be required to have as parameter with some services if the bucket name is not part of the hostname or path or where a S3 service has either just one bucket or a completely different bespoke URL for each bucket? And so, if you had the URL as parameter, the bucket is superfluous in the constructor parameters?

There are thousands of S3 API compatible services online today, makes no sense to code a driver for each of them, when the only difference between them all is the initial URL. It makes complete sense to code a single driver for all of them. Making the URL a constructor parameter, would have solved @christyjacob4 's immediate problem to add MinIO support to appwrite. As it is, appwrite can also currently only consume a single bucket per appwrite instance & config restrictions. Would also have solved the SSL/problem, and would make the S3 driver class simply what the name implies, an S3 API compatible driver, instead of what it now is, that is, an Amazon service specific driver. That is, a driver coded to a standard instead of coded to a specific vendor.

A humble request to reconsider the current architecture path of the S3 driver, if at all possible.

Check out #106

@jeffdrumgod
Copy link

jeffdrumgod commented Aug 4, 2024

please, can be generate a new version using the main codebase?
The latest merged don't generated tag version, with the resolution.

@lohanidamodar can help us ❤️ ?

@docimin
Copy link

docimin commented Aug 5, 2024

please, can be generate a new version using the main codebase? The latest merged don't generated tag version, with the resolution.

@lohanidamodar can help us ❤️ ?

As said above, please check out: #106.
This PR is not needed anymore.

@jeffdrumgod
Copy link

Hi @docimin.

This project has a commit on main branch to use generic host for S3, but does't trigged a release version.

Latest commit: 9c89ea2

latest version release commit: (version 0.18.4) 94ab875

CleanShot 2024-08-05 at 16 08 20

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants