My point is that when you say real-time in the web world, you can assume "soft real-time" because of the context. You would use specific language like "hard real-time" if it was so.
Saying context doesn't matter is just ignoring how everyone else uses language and saying that your view of it is right.
I meant that "live streaming" doesn't have a different meaning in the web world.
So now we have two terms referring to exactly the same thing, which doesn't resolve the term conflation problem I initially wrote about. The "web world" context isn't that different from the larger software engineering world that they should repurpose engineering terms.
> Saying context doesn't matter is just ignoring how everyone else uses language and saying that your view of it is right.
I am saying that web programmers do tend to use professional language wrong, that it's unfortunate, and that we should try to correct it when it happens. I don't think the first part is controversial, but apparently trying to insist on precise engineering terminology when talking about engineering systems is controversial.
This page classifies a broad definition for real-time and then breaks into different categories (hard, soft, fail-safe, fail-operational).
Is the default definition of real-time "hard real-time", or does it always need to be defined by its classification?
My point around context is that no one in the web world is saying that soft real-time systems are hard real-time systems. That would be blatant misappropriation of a term. They are saying that "real-time" defaults to "soft" in the web world. Just like "real-time" defaults to "hard" in the embedded world.
I don't know if I would classify this project as the embedded world (despite it using hardware), because it's consuming a stream of packets and isn't at the actual physical device level. I may be misunderstanding what they're doing, but I believe this to be the case.
The broader reason why I commented in the first place is that your comment feels like gate-keeping of a term when most people are going to quickly pick up on the context of how the term is being used. I understand and agree with your point around hard vs soft, but I don't think it's as clear cut as you seem to think it is regarding what the default classification is in different contexts.
