How to make extending the driver easier?

[cweiske]

To implement support for a custom AWS STS login procedure, I extended aus_driver_amazon_s3.

This required three things:

1. Custom driver class extending AmazonS3Driver with an own DRIVER_TYPE that implements hookInitializeClient to do load credentials via STS
2. Custom Extractor extending this extension's Extractor class because canProcess() and getDriverRestrictions() are hard-coded to check for AmazonS3Driver::DRIVER_TYPE
3. Custom FileIndexRepository with a copy of recordUpdatedOrCreated that is identical to this extension's recordUpdatedOrCreated except that my driver type is checked
4. ext_localconf.php to register my driver, extractor and signal handlers.

It would be nice if I could get rid of step 2 and 3.

What would be the best way to do this?
Move the driver type checks into separate methods so that overriding the classes can be made with minimal effort?
A registry for driver types that aus_driver_amazon's FileIndexRepository and Extractor support?

[Lagerregal]

With #133 the event dispatcher (PSR-14 events) was introduced:
https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/Events/EventDispatcher/Index.html

Does that help you? If you wish more events just make a suggestion. Thanks!

[cweiske]

Events and hooks only help if you want to override settings of all S3 driver instances. The concept breaks when I have a "normal" S3 driver instance connecting to a MinIO service and a second driver that needs credentials via STS.
(I know that I could differentiate by driver UID or label, but that's not very stable)

For that case I needed to provide my own driver extension so that I can select the driver type, and let my STS driver work a bit differently.
So in the end my driver extends the S3 driver here and has its own DRIVER_TYPE, and the hard-coded checks for this driver type in Extractor and FileIndexRepository make it hard.