Contrib.social

[Discussion]What approach should take with name provider modules and automators

Open on Drupal.org →
Created on 25 July 2024, 4 months ago

Problem/Motivation

This module is an abstraction layer for many different external services:

- LLMs (Such ChatGPT and Claude)
- Multi-vendor LLM providers (Such as Fireworksai and Huggingface)
- AI that isn't an LLM (Such as embedding modules or Text to Speech)
- Vector Databases (Such as Pinecone or Milvus or Databases included by multi-vendor providers such as AWS Bedrock)
- Automators - (Such as "Simple web crawler" or "Unstructured.io.) - These have been built to work with the AI Automators module and arn't strictly AI themselves but have been built in such a way they fit nicely with AI. (For example web crawlers get full HTML and then use AI to take information out of the unstructured data whereas without AI you'd probably need some way of selecting which information you need, maybe regex, maybe some rules, etc).

These services exist as seperate modules. Some of them are in the core AI module but some of them are on drupa.org

The question is, to what degree do we want to convey that all these modules are links.

Approaches to Ecosystem

- Composer depencies - We don't do anything at the naming and description level but these modules require the AI module or some submodule. This means the naming can be purely descriptive based on what it is "Fireworks.ai" it also means in theory these modules could be used without the AI module if appropriate.
- A webpage/ Documentation - Have a page that we list all the providers and automators. This could an initiative page, a documentation page or the module page itself. We could include a link to the page from the Drupal module.
- Pre_fix:- Many Drupal module work by using a prefix such as "Commerce_inventory" or "Webform_validation". When it comes to commerce you'll likely have a "commerce_paypal" and a "paypal" module that are seperate where one focused on the commerce integration and another allows you to use commerce in a different manner.
-Ecosystem:- We could tag the modules as ecosystem modules. But how widly known and used is this?
-Project Browser:- We could create an AI project browser tag that includes all the ecosystem modules and allows for filtering by different tags (Automators, Providers, Services, etc)

Proposed resolution

- Currently we are not using the prefix which has the benefit of allowing a module such as "fireworksai" to feel like it stands alone and take that namespace.
- But it feels this goes against the convention of commerce_paypal being linked to the commerce module and paypal on its own having nothing to do with the ecosystem.
- I also am worried it will be difficult for people to know what providers exist and what modules fit within the ecosystem without the ai_
- On the other side ai_ is a very generic term and so there may be many ai_ modules that arn't anything to do with the AI module which isn't the case for webform, search_api or commerce.

Any thoughts?

🌱 Plan
Status

Active

Version

1.0

Component

Discussion

Created by

🇬🇧United Kingdom yautja_cetanu

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @yautja_cetanu
  • Comment 4 months ago →
    🇧🇪Belgium wouters_f Leuven

    ik think the prefixes are very common to convey dependency or linked to
    (search_api_* commerce_* webform_* all have modules that use this kind of naming).

    Check this page https://www.drupal.org/docs/contributed-modules/webform/webform-add-ons →
    In webform there's webform_* modules and modules like address that also provide functionality outside of webform and thus don't have the naming prefix.

    I would use the same approach.

    If the module provides functionality outside of the AI module
    - Name it accordingly (fireworksai example is good)

    if the module is so tightly coupled to the AI module that it can not live without it
    - prefix it.

    Apart from that we should have a similar looking page with modules that we work with (where all the above are, both prefixed and not prefixed).
    my 5 cents.

  • Comment 4 months ago →
    🇩🇪Germany marcus_johansson

    Currently the Fireworks AI module is an provider, has plugins that works with the old AI Interpolator and it works together with the AI Augmentor, so its "more" then just a provider in this case.

    I think its not big enough to split up into an API plugin module and an AI provider module, it would not be nice having to download two modules just to have it working.

    I think good documentation and linking and even maybe lists being updated is more important then the actual data name of it, that you wont see unless you are a developer. Also note that changing namespaces is not something that is super simple to do for current modules. For future modules we could have a rule internally.

    This also means when it comes to contrib modules we can only control what we control unless we do some really weird technical solution to stop certain names to be used as providers. Someone could create a module without AI in its name, data name, description or module group that still is a provider.

  • Comment 4 months ago →
    🇩🇪Germany marcus_johansson

    One note I saw when adding a project - when you are trying to add your module to a module family that is an autocomplete. If you write AI, it does not autocomplete to the AI module, making it impossible to connect.

    We should probably call the AI module AI (Artificial Intelligence) as human readable name so its easier to find in autocomplete.

  • Comment 4 months ago →
    🇧🇪Belgium wouters_f Leuven

    Yes Marcus, also on google for example the title is very short.
    I also propose something like "AI (Artificial Intelligence)" or similar

  • Comment 4 months ago →
    🇱🇹Lithuania mindaugasd

    A.I.
    or
    A.I. Artificial Intelligence

  • Status changed to Fixed about 1 month ago
  • Comment about 1 month ago →
    🇬🇧United Kingdom scott_euser

    Think we've now decided on new architecture, and have ✨ Move out all provider modules to contrib modules Active for carrying out next steps

  • Comment 16 days ago →
    System Message

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

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024