Programmatically add OperationType

I added the invoke call.

Please review and feedback.

Thank you!

Hey, the cspell pipeline is failing due to the word 'operationtype'
Can you please fix that?

It was on purpose actually from the beginning to keep the operation types tied to the AI module, so there didn't sprout up things like Chat with Vision, Chat with Image, Chat with Picture etc. that only worked on a specific provider, thus killing the whole idea of having an abstraction layer.

The idea was to sooner or later open it up as a plugin system, when there were enough "normal" operation types in the AI module. But your idea of using a hook, might actually be a really smart solution, since it will be an operation type specifically for the installed module - and if two or more provider seems to do similar or same operation types, then it goes into the AI module.

I'll chip in the other maintainers, thanks as always Jan!

@akulsaxena: Thank you for feedback. I added operationtype to cspell because the hook name "operation_type" would be misleading.

@marcus_johansson: Thank you again for feedback and the strategic thinking. We need this for search-api because AnythingLLM directly provides an endpoint for the indexing (embedding incl. vdb).

Thanks, 'operationtype' was added to cspell file and all the pipelines are green now
Changes LGTM
Moving to RTBC+

Could you provide any insights into why you wanted a new operation type?

Its possible that the hook alter is good but the abstraction layer stops being one if every provider just has it's own operation type

From the sounds of things that operation end type looks like it woild be good in the module? An embedding with llm endpoint?

Similarly the reranking endpoint seems like a good one for the ai module.

Maybe it's worth including though anyway bevause would it be that bad if the future has end points being in their own api modules?

Like you could have a translation endpoint that could swap between Llms and ML or something.

Actually I do agree with this change because I don't like it as I'd prefer if we thought this through and had some plan for operation types but it's sometimes good to do things organically and see what happens. I do wonder if operation types are going to morph into something where there are tons of different specific common functions that you wsnt to swap out (an alt text generation endpoint).

> Could you provide any insights into why you wanted a new operation type?

AnythingLLM provides ONE endpoint for embedding AND storing embedded data in vector database. AnythingLLM is an abstraction layer also (you can choose which LLM for embedding and which VDB for storing the data). This means we cannot separate embedding and saving in the vector database.

I added a test for adding an operation type.

first to get it out of the way: I am not trying to derail this issue or question the validity of it, I think it is a good direction, but I have some concerns of how this all plays along. But maybe I am missing something. When adding a test for the hook I added a new type based on the existing ones and I observed that it seems a bit "disconnected".

In particular I think it makes sense that there is an attribute on the interface that we expect providers to implement. But with this hook we just let the ai module know that there is another operation type, we don't make sure that the altered operation types have an interface etc. Do we want to make this more consistent? ie discover operation types in modules src/OperationType/* rather than having a hook? (Having the hook would still allow renaming or removing operation types so there is still a use case for it.)

TBH at some point we need to bite the bullet and make these a Drupal Plugin, surely?

FYI: I am not currently depending on the patch, because getProvidersForOperationType() does not test whether the OperationType has been registered before.

I can simply add any identifiers in my provider's getSupportedOperationTypes().

See AiProviderPluginManager::getProvidersForOperationType().

I think the operation types the way they are now makes them a bit different than plugins.
Because if your provider is expected to implement the interface it becomes a dependency, whereas with normal plugins you can create a plugin for a module you don't otherwise depend on.

That said, I am sure we can use the discovery methods already available. and make it "like a plugin" without being a real plugin (or needing to change namespaces etc)

So I made a little change, and use a plugin manager to get the operation types.
This change demonstrates that we could replace the current logic with a real plugin manager.
But operation types are not really plugins in the traditional sense. Because the plugin class is an interface one can not simply create a plugin instance.

But when going down that route we could go a step further and use the plugin information derived from the in situ plugin manager to make some assertions. so for example instead of just asking the provider which operation type it supports we can check which interfaces it implements.

This looks great now, I will wait to merge this until we have ✨ Normalize Structured responses Active issue fixed and this all together with the 📌 Research normalize function calling in Chat operator Active goes into the 1.1.x release since this is more then just minor feature updates.

I did a minor update for the new structure of the inputinterface. This now is merged with 1.1.x - thanks everybody!

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

Maybe add a change record → ?