Are `ISimulator` and `IClientSimulatorImpl` well named?

[interim17]

What needs to happen?

ISimulator

The three current implementations of ISimulator are client, remote and local, and they manage streaming, requesting, and handling frame data and metadata from various data sources that may be:

• Octopus serving a precomputed trajectory
• Octopus serving a converted file
• or Octopus serving frames from a procedural simulation.
• a local file
• a local procedural simulator
• a third party remote API

These instances do not simulate anything, or do business logic related to simulation. They manage the connection between a data source and the controller.
Possible names for what is currently called ISimulator:

• IDataProvider
• IDataStreamManager
• ISimulationStream
• ISimulationDataPipeline
• IDataBroker
• IFrameProvider
• ISimulationDataSource

IClientSimulatorImpl

Is somewhat a contradiction in terms as it is an interface that defines a set of methods that are required to be present on procedural simulations, but is not an implementation it is an interface/contract.
It's also confusing that ClientSimulator implements ISimulator and the various procedural simulators implement IClientSimulatorImpl. Internally ClientSimulator refers to these procedural simulations as localSimulator.
It does make sense to call these instances "simulators" as they actually do the business logic involved in simulating something.
Possible names for what is currently called IClientSimulatorImpl:

• ISimulator honestly more accurate, but maybe confusing to people familiar with the old system
• ISimulationEngine
• IProceduralSimulator

Why should we do this?

Decide if its worth renaming here.

When does this need to get done?

[toloudis]

Interesting idea!

1. You write "these instances do not simulate anything", but you have included many instances that actually DO simulate things. That being said, some of your alternatives are also reasonable names. ITrajectoryDataProvider seems decent but then I wonder if the method names still make sense...

2. IClientSimulatorImpl is trying to capture that it's a layer for code that runs entirely on the client (in browser). We need an implementation of ISimulator for trajectory data that's entirely in js in the browser, and then most of that is boilerplate for all the different possibly client simulator types. So that's why there's a second interface introduced there.
   Here's how I would say it:
   ClientSimulator is a ISimulator which will entirely run using js plugins in the browser. The js plugins must implement IClientSimulatorImpl so that they don't have to provide complete implementations of ISimulator. (ClientSimulator captures the shared boilerplate code).

[interim17]

Interesting idea!

1. You write "these instances do not simulate anything", but you have included many instances that actually DO simulate things. That being said, some of your alternatives are also reasonable names. ITrajectoryDataProvider seems decent but then I wonder if the method names still make sense...
2. IClientSimulatorImpl is trying to capture that it's a layer for code that runs entirely on the client (in browser). We need an implementation of ISimulator for trajectory data that's entirely in js in the browser, and then most of that is boilerplate for all the different possibly client simulator types. So that's why there's a second interface introduced there.
   Here's how I would say it:
   ClientSimulator is a ISimulator which will entirely run using js plugins in the browser. The js plugins must implement IClientSimulatorImpl so that they don't have to provide complete implementations of ISimulator. (ClientSimulator captures the shared boilerplate code).

This is very interesting context for me!

1. Can you be more specific about how these examples simulate something? For example in the case of Octopus serving a pre-computed trajectory, a simulation was already computed at some other time, and octopus is serving it as a database would, in a sense the frame data itself is "simulating" something, but the ISimulator interface is just providing those frames, not doing any business logic. Does that qualify as "simulating something"? I promise I'm not trying to be pedantic here, genuine question.

2. I think I'm understanding this, but I have a couple things that still feel a bit unclear.
   For example, you say the plugins don't have to provide "complete implementations of ISimulator" but they don't seem to provide any implementation of ISimulator. None of the local simulators implement any of the methods of ISimulator, and some of the ISimulator methods don't necessarily make sense in the context of a plugin. For example within the BindingSim it doesn't really make sense to pass arguments into requestFrame as you can't request frames by specific numbers or times. That also makes certain controller methods a little wonky, since the simulation code has no concept of frames or times except to increment by one step when update gets called.

For context I showed these interfaces to Chris Hughes and Tyler yesterday in a standup and they seemed confused by the naming having both I at the beginning and Impl in an interface name, which is part of why I raised this issue.

In response to your two points I'm wondering if we should leave ISimulator as it is but rename IClientSImulatorImpl something like IClientSimulatorPlugin to show the relationship it has to ClientSimulator as something that is implemented BY the client simulator, not something that is an implementation OF the client simulator. Or we can leave it all as is, the biggest target for me is to get clear on my understanding so we can make the necessary updates to: visData, cache, and simulators so that all the streaming behavior, pre fetching, live sim control and public API interactions on the controller happen in a fluid, bug-free way.

[toloudis]

1. The ISimulator abstraction is supposed to hide how the frames get generated so the viewer doesn't care whether it's running live or precomputed.
2. I totally get that IClientSimulatorImpl is a confusing name. It could be renamed to IClientSimulatorPlugin... and another possibility is to remove that interface and just make them overridable methods of ClientSimulator. Then all the specific IClientSimulatorImpls would instead extend ClientSimulator. The point of this abstraction was to let ClientSimulator have all the boilerplate code that was the same across all different client simulators, and the specific simulators are responsible only for the three simple methods in the interface. I slightly prefer the simulations themselves to be their own classes so they can maintain their own state but the important thing is just the clear interface contract.

In discussing this, we also identified that the bigger problem is that goToFrame is ill-defined for client simulators that may or may not be caching anything. We need to much more clearly state the contract and expected behavior for this.