Moved quantum machine interfaces to its own folder

[cesarzc]

Since new interfaces will be added shortly, moving all these related source files to its own folder will help keep everything organized.

[swernli]

I mentioned this in #627 (comment), but realized the discussion is probably better had here. "Machines" is such a generic name for a folder, that I worry it could be confusing for folks not already familiar with our object hierarchy what to expect to find there. I haven't been able to come up with any more descriptive names, so maybe we need something in a readme that clarifies what this folder and the term "Machine" are describing?

For me, it's a bit of a disconnect to call these machines, since that isn't usually a word I associate with the infrastructure for submitting something to a service, but I'm at a loss to come up with an alternative. As I've often joked, English feels insufficiently descriptive for our needs ;)

[cesarzc]

I mentioned this in #627 (comment), but realized the discussion is probably better had here. "Machines" is such a generic name for a folder, that I worry it could be confusing for folks not already familiar with our object hierarchy what to expect to find there. I haven't been able to come up with any more descriptive names, so maybe we need something in a readme that clarifies what this folder and the term "Machine" are describing?

For me, it's a bit of a disconnect to call these machines, since that isn't usually a word I associate with the infrastructure for submitting something to a service, but I'm at a loss to come up with an alternative. As I've often joked, English feels insufficiently descriptive for our needs ;)

Yes, I couldn't come up with a good name for the folder yesterday when I was doing this. Maybe RemoteExecution would be a better name for it?

[bamarsha]

Maybe an *Executor suffix? IQuantumExecutor, IQirExecutor, etc. (Although technically they're executed by the Azure service itself, but the interfaces can schedule execution.)

[swernli]

These classes submit jobs to Azure, but noun form "submitter" is such an awkward word. In a sense, these classes are what allows the program to act as a client of the Azure service, so is there any formulation of "client" that might work here?

[cesarzc]

I prefer either Submitter or Executor, the former doesn't sound that awkward to me, than Client because it is a very overloaded term.

[cesarzc]

@SamarSha, @swernli renamed the folder to Submitters but didn't rename the interfaces since they are public.

[bamarsha]

Do we always want to keep the *Machine suffix, or transition to a *Submitter suffix in the future?

[cesarzc]

Personally, I think it would be great for us to transition to the *Submitter suffix in the future.

[bamarsha]

Should new interfaces use the existing *Machine suffix for consistency, or the new *Submitter suffix?

[cesarzc]

I think the new interfaces should use the *Submitter suffix but I would like hear what is your preference @SamarSha and @swernli

[bamarsha]

I like Submitter more than Machine, since it's more descriptive, so it makes sense to use that for new interfaces. The downside is that it's inconsistent with the existing interface names, but if we plan to eventually transition to the new names (and deprecate the old ones) that problem will go away.