SimulatedLocalJob is not JSON Serializable

[mpharrigan]

It would be really helpful to have AbstractJob's descendants be serializable to keep a record of job_id and all the other wonderful goodies within.

[mpharrigan]

Although it gets tricky, since the job is one part data chunk (id, create_time, update_time, description, labels, ...) and one part future (get_results, cancel, ...). I'd really only need a record of the data chunk part.

Does it make sense to factor out a JobInfo (data)class from the AbstractJob future, which can then just have a reference to the data class ? @dstrain115 @wcourtney

[mpharrigan]

This is pretty similar to the private EngineJob._job field, which is a quantum.types.QuantumJob proto. What's best practice here? should we wrap this in a Python class or make this proto part of the abstract interface and make it json serializable? also cc @verult

[verult]

Wearing my Cirq triage rotation hat: Marking as accepted as providing serialization for the data part makes sense to me, but the best practice remains an open question.

What's your use case, by the way?

[mpharrigan]

we like to keep a record of all the job stuff to retrieve results, cross-check with calibrations, get metadata, etc while running experiments

[mpharrigan]

closing in favor of #5152 which is serializable and only carries along the things we care about.