Document the "SDKs only" method waitForTask

[brunoocasali]

An excellent context can be found here: meilisearch/integration-guides#243.

Also, I've discussed this privately with @dichotommy proposing the creation of a section in the docs where we can adequately document the usage of this kind of function.

The subject is this method, which is present in every SDK:
https://github.com/meilisearch/meilisearch-php/blob/main/src/Endpoints/Delegates/HandlesTasks.php#L38

What we expect to be present in the docs is:

• Why you should be careful to use this method.
• What happens when you use this method.
• How to use this method if you are willing to take risks.
• How to customize the method parameters to make it eternal if you want to.

CC: @meilisearch/integration-team (let me know if I miss anything)

[guimachiavelli]

@meilisearch/integration-team, is this still relevant?

[brunoocasali]

By using the wait_for-like methods the user should be aware of major performance bottlenecks they could face if used recklessly.
For example, if you have a waitFor and your instance is processing a dump, you may wait minutes in the thread, causing the user a bad experience, keeping other services waiting like database queries, and much more.

So, it would be nice to document that in an official way, but I don't know how integrations-only content would fit in the docs these days 🤔. I also don't know about your other priorities, so it is up to you! I would classify this issue as a "nice to have" :)

[guimachiavelli]

Yeah, so, a while ago (early 2023, pre-layoffs) I did some research on SDK documentation and it's a bit of a huge topic. We got two main takeaways from it:

• With our resources, each SDK should have their docs in whatever format is most common for each language (e.g. rustdoc for Rust and so on)
• Due to how SDKs are very tightly connected to each language (and its accompanying common best practices and etc), documentation of multiple SDKs should be more of a joint effort between technical writer and programmer

Given how most of our SDKs are not even maintained by us nowadays, and how SDKs are not a strategic focus right now and for the foreseeable future, I'm closing this as not planned.