Rename ParaId and para_id

[rphmeier]

"Para" was a catch-all term we created in 2019 to abstract over parachains and parathreads. As Polkadot's architecture has evolved, those concepts have unified and no longer encompass all the things which can be done on Execution Cores.

With that in mind, let's discuss a name-change in the codebase and implementers' guide. Suggested alternatives are Task(Id) and Process(Id), to mirror the CPU metaphor we have been applying with cores.

[daredevil3435]

I would like to work on this issue. How do I get started?

[rphmeier]

First we have to determine what the new name will be, then the actual PR would be a simple search-and-replace for para, para_id and ParaId with the new name

[xlc]

TaskId is too generic and will be super confusing with other TaskId that we will have (e.g. #206).

I actually think the name Para is good as for parallel execution. Rename it will be:

• confusing for some period of time
• a lot of work. search-and-replace is not that easy when you need to make sure everything (EVERYTHING including downstream projects and SDK and dApps) still compiles.
• for what benefits?

[burdges]

I'd think ParaId should remain as the first identifier parachain teams see, but internally what we schedule onto cores, or core groups paritytech/substrate#7441, takes some different form, only some of which parachain teams see.

Ideally, one might chart out or classify the parachain-like constructs before doing renames which risk both annoying people and winding up flawed. We do not know this hierarchy yet, right?

We originally selected the term availability core, or now execution core, because the approvals protocol aka machine elves has vague parallels with task scheduling in OSes, but core never really clashed with common parlance like thread or task do. We could give parachain teams clearer names like para-job or para-task, while internally we've terms like core-share or core-slot, or even terms like trip, quest, etc. ;)

[gavofyork]

"Para" is nonsense term. It just happens to be the common prefix of "parathread" and "parachain". Parathreads has been dropped as a term and in the Coretime model, a parachain is not first class concept within the Polkadot UC; a parachain is merely a Substrate-based blockchain whose state transition is secured by utilising a Polkadot Core.

In the Coretime-centric model, a core is scheduled with some stateful workload to do on a per-block basis. Mirroring the generality of the Coretime model, it makes sense to have a general term to describe this workload. We can reasonably argue over different terms such as WorkloadId, ProcessId, TaskId, ContinuationId, but the only thing going for the ParaId is that a rename is not required and I'm afraid that carries little weight with me when deprecation, type aliases and search/replace functionality all exists.