Replies: 1 comment 1 reply
-
|
I'm sympathetic! In the source, I've been somewhat careful to abstractly call it a "job source." Hi. That said, as soon as it came time for a user-facing name like the environment variables for a Sv1 source, I casually used the word pool 🤦🏼♂️. In my defense—it is nice and compact, and everyone immediately recognizes what it means. Naturally, I'm drawing towards "source", "job source", "mining job source", etc., depending on the context. Visualizing some options:
MUJINA_SOURCE_* feels the most natural to me. Maybe UPSTREAM being second best. Keep in mind there will be multiple "sources." Not sure yet what the syntax is going to be. Might be better to put all the variables on one line, e.g.: Okay, bikeshedding time. Please give rationale for why, e.g., you object to SOURCE, if you do. E.g., "It makes me think of X, which is confusing." |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Most legacy Sv1 was written under the assumption that all deployments consist of pointing a Mining Device directly to a Pool. That happened before the industry started moving towards more elaborate and optimized deployment schemes.
As a consequence, we see "Pool" written in every place where we need some reference to an upstream Mining Server.
This disregards alternative deployments, where work could be coming from different sources, such as:
So just using "Pool" everywhere is arguably misleading, as it conveys limited functionality and closes UX doors that don't necessarily need to closed.
While this mindset was ossified in the legacy proprietary mining industry, now we are having the opportunity to do things "the right way". So we should leverage that!
A few alternatives to "Pool":
Beta Was this translation helpful? Give feedback.
All reactions