🚀 Feature: make "ImageUploader" pluggable.

[michaelsafyan]

Which component is this feature for?

Traceloop SDK

🔖 Feature description

More clearly define the interface of ImageUploader, make it an abstract base class (moving current implementation to a TraceloopImageUploader), and define a mechanism for constructing/selecting/plugging different implementations (as well as guidance regarding where different implementations of the base class ought to live).

🎤 Why is this feature needed ?

In order to allow this feature to work with other backends/vendors, there needs to be a way to swap out different implementations.

For some additional context, I'm currently working on sample code for Google Cloud / OpenLLMetry integration:

• GCP/Traceloop Integration Example
• Traceloop Doc Update
• OpenLLMetry README Update

As part of that, I am implementing an alternative ImageUploader:

• GcsImageUploader

There is a bit of a code smell, though, in that it would seem wrong to inherit from traceloop.sdk.ImageUploader due to traceloop.sdk.ImageUploader not being purely abstract. On the other hand, simply following the shape/outline of traceloop.sdk.ImageUploader without inheritance seems error prone.

Separately from the above concern, I am thinking about where such an implementation ought to live in the long run and how to make alternative implementations of this easily discoverable. Where images get stored could conceivably be orthogonal to which observability backend is used; for example, as long as there was a way to configure the ACLs to grant the observability backend the necessary access, the observability backend and storage backend might be different [e.g. a Traceloop user storing images in GCS; a Google Cloud Observability user storing images in S3].

✌️ How do you aim to achieve this?

It would be a good start to just split ImageUploader into an abstract base class and a concrete, default implementation.

Beyond this, clearer comments on the interface to make the meaning clear. Perhaps some slight renaming (e.g. from image_file to base64_data_string, if I understand its format correctly). Type annotations, too.

Then, after that, perhaps some structure around how to organize implementations of it. Perhaps putting the concrete implementation in a separate file in a subfolder for implementations, along with instructions on where/how to contribute alternative implementations.

🔄️ Additional Information

No response

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

• I checked and didn't find similar issue

Are you willing to submit PR?

Yes I am willing to submit a PR!

[nirga]

Sounds good @michaelsafyan! You marked you're willing to make this PR so happy to support you in the process :)
I agree this should be abstract - we're coming from golang where abstract classes don't really exist so that's why we chose this "duck-typing" design :)

[michaelsafyan]

Thanks, Nir!

I've proposed the shape of a solution here:

• Library for uploading blobs as part of instrumentation #GenAI #MultiModal open-telemetry/opentelemetry-python-contrib#3065

The more I think about it, the more I'm inclined to approach this by:

1. Establishing the interfaces first in OTel Contrib Python.
2. Migrating the existing ImageUploader implementation in OpenLLMetry to that interface.

Thoughts?