Move Bundles to Interface system and call it Provider Operations Type

bundles is a very generic name

Yes, and name also clash with Drupal entity bundles.

not extedable and can't really have any functions attached to it

Yes, having it with functions will be better.

In my code code, I abstracted further deep under the name "output" back then, also with functions, examples:

namespace Drupal\custom\Outputs;

class textOutput extends baseOutput {

  public function provides() {
    return ['text'];
  }

  public function setText($text) {
    $this->data['text'] = $text;
  }

  public function text() {
    return $this->data['text'];
  }
}

namespace Drupal\custom\Outputs;

class openaiModerationOutput extends baseOutput {

}

(the same as baseOutput)

namespace Drupal\custom\Outputs;

class openaiChatOutput extends baseOutput {

  public function provides() {
    return ['role', 'text', 'completion_usage', 'completion_model'];
  }

  public function role() {
    return $this->data['response']['choices'][0]['message']['role'] ?? NULL;
  }

  public function text() {
    return $this->data['response']['choices'][0]['message']['content'] ?? '[Result not found]';
  }

  public function completion_usage() {
     return $this->data['response']['usage'] ?? NULL;
  }

  public function completion_model() {
     return $this->data['response']['model'] ?? NULL;
  }

}

namespace Drupal\custom\Outputs;

class stabilityaiImageOutput extends baseOutput {

  public function provides() {
    return ['imageURLs', 'count'];
  }

  public function imageURLs() {
    $urls = [];
    foreach ($this->data['response']['artifacts'] as $key => $val) {
      $urls[] = $val['url'];
    }
    return $urls;
  }

  public function count() {
    return count($this->data['response']['artifacts']);
  }

}

etc.
But 'text', 'role', 'text', 'completion_usage', 'completion_model', 'imageURLs', 'count' as basic data types don't have functions.

For instance an ElevenLabs TextToSpeech would require you to take a choice of the voice you want to use

Azure text-to-speech accepts SSML XML document, where one can define full blueprint everything and in detail of what Azure has to produce: 10 different voices if needed each saying a different thing in a different intonation in different language at specific times, adding pauses, sounds, music etc. It is an old API available for a decade, but highly flexible.

By default it could just accept voice and text, but provider could have a separate and unique helper methods to do various common tasks with a specific API. For example, doChatToSpeech (narrate multiple voices talking with each other), or doSsmlToSpeech (where anything would go).

---
These are my first review for now, I will look into this further.

We had an internal discussion about this and the conclussion for a best version is:

• Rename it to Operation Type instead of Bundle.
• Do not use a Plugin system for it, it does not need to be that flexible. An interface is enough.
• The interface constructor defines how to to create it and how a DTO would look like.
• The DTO would have both the normalized response and the raw response as well as any metadata that wants to be given, since its a DTO certain type of usual metadata can be defined.
• The providers then just implements the interfaces that they support.
• The input and output can still take mixed for developers that don't care about reusability, for developers that care about reusability they can use the interface.
• If a wrapper function is needed in the ProviderClientBase then we can take the interface as an initial parameter, similar to how the bundle enums works now.

Marcus_Johansson → credited andrewbelcher → .

Marcus_Johansson → credited justanothermark → .

Marcus_Johansson → credited wouters_f → .

Marcus_Johansson → credited yautja_cetanu → .

Automatically closed - issue fixed for 2 weeks with no activity.