DDD wrote: ↑Mon Oct 21, 2019 9:30 am
1) Yes, I want to use S3-like storage and I already use it in a lot of my script.
If you already have a solution, what parts are you currently looking for?
2) No, I don't want to use a proprietary objectstorage like google Cloud or MS Azure that is not a defacto standard and with this only used by one vendor.
Thank you for confirming that Amazon's S3 API is not compatible with the other two of the Big Three public cloud vendors.
They all offer object stores, and at least Azure offers import capabilities from Amazon S3, but their APIs are not interoperable. It may be that the Oracle v Google decision is what's keeping replication of Amazon's API limited to smaller vendors at this time.
That said, Amazon's clear marketshare lead does indeed make it a good first choice for API adoption.
And most important: You don't need all hundrets of API calls. It's fine to start with the 10-20 most common ones.
Which of those are not currently supported in your existing scripts? And would the REST API work for your use-case, or does your app specifically require the SDK?
REST should be accomplishable with relative ease in LiveCode Script. In those cases where the SDK is needed we could use LiveCode Builder.
Just as a hint: Objectstore is the way to go in the future for a lot of usecases. I believe that LiveCode is not only missing a big trend but even a big opportunity if S3-like objectstore is not supportet in the future.
Very few languages offer direct support for the vast-and-growing range of storage options as elements of the language itself by the core team. In most cases such things are provided as optional add-ons by the community using the language. This can be the case with LiveCode as well.
Key-value stores with extensible metadata are indeed growing in popularity for their simplicity and scalability. I would be happy to see what we can do to bring together interested members of our community to provide and maintain support for Amazon S3 and other object stores.
We can start with the portions you have working now, and focus efforts on the portions you need to add next. Your suggestion of limiting initial scope to a subset of fewer than two dozen API calls makes the project attractively actionable.