Initial MVP task breakdown

[felixarntz]

This issue proposes a breakdown of all the work based on the proposed architecture (see #2) to get to an MVP of this SDK, also taking into consideration the development roadmap (see #8).

What is called MVP here is largely equivalent with what is "Phase 1" in #8.

Purpose

The primary purpose of this issue is to define the breakdown and later, once agreed upon, act as an overview issue to track the work until the MVP:

• The breakdown below is largely sequenced.
• Each checkbox should be considered an individual issue / pull request.
• Some things may be worked on at the same time, and if someone wants to tackle multiple subsequent steps in one session (without having to wait for PR approval), it's always okay to create a branch based on another branch for an unreviewed PR.
• Many tasks, especially in the "Foundation" section, are probably fine to start with a pull request directly. Some others are more complex and would likely benefit from some prior discussion in an issue. This can always be decided on a case-by-case basis.

Let's use the discussion in this issue to shape/refine this breakdown. As we discuss, iterations should be made directly on the issue description to keep things up to date in this source of truth.

Breakdown

Foundation

These almost entirely build on top of each other and therefore should mostly be sequenced.

• Implement all enums for the implementer API and extender API (see Adds all the enums #25 and Adds enum unit tests #26)
  • See AiClient.*.Enums and AiClient.Providers.*.Enums namespaces in the class diagrams.
  • We won't be able to use PHP enums due to supporting PHP version support, but we can implement a very basic class foundation (e.g. AbstractEnum, with things like checking whether a given value is part of the enum) that effectively is our enum infrastructure.
• Implement all data transfer objects for the implementer API, except omit any related to function calling and embeddings (see Adds Implementor Data Transfer Objects #28 and Adds DTO array transformation and JSON serialization #30)
  • See AiClient.*.DTO namespaces in the class diagrams.
  • This also needs to include a few interfaces where appropriate, e.g. something to define the getJsonSchema() method commonly found.
  • Function calling will be implemented in a future milestone after the MVP.
• Implement all data transfer objects for the extender API (see Adds Extender API DTOs #31)
  • See AiClient.Providers.DTO and AiClient.Providers.*.DTO namespaces in the class diagrams.
• Implement all interfaces (contracts) for the extender API, except the ones related to HttpClient and Authentication (see Adds Provider interfaces #35)
  • See AiClient.Providers.Contracts and AiClient.Providers.*.Contracts namespaces in the class diagrams.
  • The HttpClientInterface and AuthenticationInterface omissions are due to additional considerations regarding ecosystem interoperability, which needs some extra consideration and therefore is better implemented separately.
• Implement the extender API interfaces (contracts) related to HttpClient and Authentication (see Adds support for Provider HTTP Handling #47)
  • See AiClient.Providers.Contracts namespace in the class diagrams.

Main API entrypoints

These are mostly independent of each other and therefore can be worked on in parallel, except for the last point covering AiClient.

• Implement infrastructure (provider and model classes) for a generic OpenAI API compatible provider, covering text generation (without function calling) and image generation, and include basic setup plumbing for Anthropic, Google, and OpenAI providers using this generic implementation (see Provider base and implementation for Anthropic, Google, and OpenAI via common abstractions #39)
• Implement AiProviderRegistry (see Implement ProviderRegistry with comprehensive test suite #38)
  • See AiClient.Providers namespace in the class diagrams.
• Implement PromptBuilder, except for any methods related to operations, streaming, text to speech conversion, speech generation, or embedding generation, and leave the terminate methods unimplemented (see Add the Prompt Builder #49)
  • See AiClient.Builders namespace in the class diagram.
  • The omissions are crucial, as these aspects will be added later than the MVP. While it's reasonable to already cover them in the foundation, as the API design is clear and that part is purely about contracts and DTOs, the actual implementation is substantial and therefore makes sense to be deferred (also see Development roadmap #8).
  • The terminate methods depend on AiProviderRegistry being done first. They also are extra complex, and therefore should be handled separately.
• Implement AiClient, except for any methods related to operations, streaming, text to speech conversion, speech generation, or embedding generation (see Add the AiClient with testing suite #55)
  • See AiClient namespace in the class diagram.
  • All methods not related to provider handling or to the fluent API are part of the traditional API and should wrap the respective fluent API logic. In other words, these can be implemented by calling the fluent API, even if the actual logic in the fluent API terminate methods is still missing.

Tying it all together

These are mostly sequential.

• Properly register the 3 initial providers on the default AiProviderRegistry instance
• Implement the terminate methods on PromptBuilder

[felixarntz]

@Jameswlepage @JasonTheAdams Would love to get your thoughts on this proposed breakdown for the MVP (~phase 1 of #8).

I could see completing each of the 3 breakdown sections in roughly 2 weeks, so overall roughly 6 weeks. Though this very much depends on the spectrum of how much time we have available, how effectively we can work together, how many additional discussions may come up that could (whether for good reasons or not) delay progress.

I know it was brought up before to maybe have something by WordCamp US, and I think that's potentially doable, but per the above it's tight. My impression is that it's far more likely by WordCamp US we'll have something very close to ready, which we can show to other attendees, but maybe it won't be launched yet. FWIW, I think there's a good chance we would be able to finish the last bits and launch at Contributor Day with the additional focus time there, which that in itself would be a great success story.

Pending #8 (comment), we could further reduce scope by removing image generation from here and making that the highest priority after the MVP.

[JasonTheAdams]

Good breakdown, @felixarntz! We'll want to get this updated after the domains are updated since they're referenced here.

I feel fairly optimistic about the timeline, but agree that there are a lot of potential unknowns. I'm personally pretty invested to get cracking on some code PRs once we wrap up planning and architecting. So I guess we'll see just how fast we move once we get going. I'm also hopeful the weekly chat will help.

My only thought on this is the last part wherein we register "the big three" providers. Thinking of the greater project, I'd be inclined to get moving on the WP integration even once we have a single provider working. Having a plurality of providers is a good thing to have for the sake of the client, but I wouldn't want it to hold up the integration work to get to a proof of concept as quickly as possible.

I'm 50/50 on punting image generation. I think quite a few plugins could find it a highly useful feature, and it's an important part of being able to say to an AI things such as "make this page for me". I'd probably prioritize this above supporting multiple providers.

[felixarntz]

We'll want to get this updated after the domains are updated since they're referenced here.

Absolutely, I have this in the back of my head and will do once the approach in #21 (and #23) is settled 👍

My only thought on this is the last part wherein we register "the big three" providers. Thinking of the greater project, I'd be inclined to get moving on the WP integration even once we have a single provider working. Having a plurality of providers is a good thing to have for the sake of the client, but I wouldn't want it to hold up the integration work to get to a proof of concept as quickly as possible.

The main reason I think "the big three" is important to have early is remaining neutral. This was an important part of the discussion we had a few weeks back on Slack regarding provider support. Even if we can justify it with "we needed to move fast", a WordPress SDK launching, even in an early version, with only Anthropic, or only Google, or only OpenAI sends a problematic signal that is easily interpreted as "oh, WordPress is prioritizing this provider".

I completely agree with you that from a technical perspective we don't need to have 3 providers to proceed. But for the above reason I feel pretty strongly that this is the right thing for the project.

I'm 50/50 on punting image generation. I think quite a few plugins could find it a highly useful feature, and it's an important part of being able to say to an AI things such as "make this page for me". I'd probably prioritize this above supporting multiple providers.

See above why I wouldn't prioritize this over multiple providers. Otherwise, I of course agree this is the next most important thing. But if, from a timeline perspective, we were able to get something ready by WCUS if we don't include image generation, I'd say we should leave image generation for the first thing after.

[felixarntz]

The issue description has been updated to reference the latest namespaces from #23.

• Note that the AiClient namespace in the actual Mermaid diagrams is called AiClientNamespace to avoid conflict. But the real name is AiClient.
• Some of the namespaces mentioned use a wildcard *. If so, this simply means any single sub-namespace in that wildcard slot should be covered.

[felixarntz]

@JasonTheAdams As you open new PRs for the breakdown, could you add links to them to the issue description as you go? I just added your initial PRs accordingly.

[JasonTheAdams]

@felixarntz Can do! 🫡

[dontfeedthecode]

The main reason I think "the big three" is important to have early is remaining neutral. This was an important part of the discussion we had a few weeks back on Slack regarding provider support. Even if we can justify it with "we needed to move fast", a WordPress SDK launching, even in an early version, with only Anthropic, or only Google, or only OpenAI sends a problematic signal that is easily interpreted as "oh, WordPress is prioritizing this provider".

Just a thought, but on this basis would support for Ollama make sense as a way of further "democratizing" model access on release? Both Prism and LLPhant support Ollama for anyone wanting to roll their own LLM.

[Jameswlepage]

@dontfeedthecode there's an issue here; #6 chatting about that. IMO, Ollama could be supported by the OpenAI Provider as it's the same API iirc. We could make the clear in the docs, or "fork" the Oai provider to Ollama branded.

[felixarntz]

@JasonTheAdams @Jameswlepage Based on what we discussed earlier on the AI sync, I updated the task breakdown to focus on a generic OpenAI API compatible provider implementation, which we can then use for baseline support of Anthropic, Google, and OpenAI.