simplify job manager: add_backend without name

[soxofaan]

To add a backend to MultiBackendJobManager, one has to give it a name, e.g.

job_manager.add_backend("foo", connection)

But that name has very little purpose. Can't we drop the requirement to provide a name, and just fall back on the connection url?

[HansVRP]

@manugv best to first discuss with stefaan as we need to remain backwards compatible.

Sounds like an easy python-client issue wherein the name in add_backend should be made optional.

This ticket also allows you to explore the multijobmanager. Examples on its usage can be found in the community examples

[jdries]

@soxofaan isn't the purpose of the name to allow tracking jobs on multiple backends? Or do you suggest to generate an identifier internally?

[soxofaan]

Indeed, I understand it is important internally, but requiring the user to give it a name seems unnecessary, especially for users that only use one backend anyway.
I think the backend URL itself could indeed act as fallback identifier

[manugv]

I have another question: If we remove the identifier then will it not remove a feature where someone is working on two backends and specify different jobs using the identifier (in pandas Dataframe)? Or this feature is unnecessary?
If unnecessary, I will remove the identifier and if not then I will make it optional.

Second: in both cases removing the identifier or making it optional, will break backward compatibility unless a new function is created. So how important is backward compatibility in this case?

[soxofaan]

Maybe I was not clear in my original description, but I would just remove the requirement for the user to provide a name (and use the backend URL as fallback), but keep it as an option if they want it (and to stay backward compatible )

[soxofaan]

As discussed earlier today: this is pretty low priority ticket (to simplify the user experience a bit), we probably have higher prio tasks to tackle first.
(also note that it's probably not trivial to do this in a backwards-compatible way, so the cost/benefit ratio is a bit off in that sense)