CLI Parity

[aaschaer]

Here are the remaining gaps with the hosted cli other than the rm command which we already have an issue for. I don't think anything here is worth not deprecating the hosted cli for but @ranantha should confirm this.

Missing API support:

• the ability to get subtasks of successful delete tasks *
• retrying code faults and subtask_id fields on globus task show -t *
• expansions field on globus task show
• credential_subject on globus endpoint show

(* both of these have a disclaimer about potentially not being available in future versions of the cli)

Not missing API support:

• --myproxy-lifetime option for globus endpoint activate
• ability to delete servers by hostname with globus endpoint server delete
• globus task wait doesn't show a progress bar, files completed, or mb/s

[sirosen]

The subtask functionality is all deprecated. (Hence the notes about not being available in the future.)
We can just strike those from the list.

---

Task expansions and Endpoint credential_subject are both simple fields.
If they're added to the API, we'll add CLI support, of course. Not much to say about those.

---

--myproxy-lifetime is very straightforward. We should just knock that out.

---

globus endpoint server delete by hostname is a little fiddly and not important enough to consider blocking.
We'd have various specialized cases to handle (multiple matches, no matches, etc), and users can already endpoint server list followed by endpoint server delete. It's not hard, but unless someone comes to us with a need for it, it's unnecessary complexity.

If someone were scripting endpoint server deletion by hostname, that would be legitimate, but I haven't heard of anyone doing that.

---

globus task wait can't show a progress bar. We don't have the necessary information to render one. I doubt that the one shown by the hosted CLI is accurate, or it may be based on information not exposed through the API.

Files completed and mb/s , both of which can be seen with a simple globus task show, are not important enough to disrupt the currently simple/clean output.
Printing . to indicate that the wait is still polling (and that the command didn't hang somewhere) is good and useful.

[sirosen]

After doing a quick search of hosted CLI usage history, it looks like server-remove by hostname is the most common way that command is used.
So I was utterly wrong.

It may be worth doing this. Unfortunately, I can't think of any particularly clean way of exposing that in the API. It seems to conflict a little bit with the REST model.

We can do the current server-remove -p behavior with pretty low effort by just doing a list, check for full URI matches, check for hostname:port matches, and then finally check for hostname matches.
There will be no URI-parsing necessary, as the API stores these values in separate fields.

I'll try to write it up sometime soon.

[sirosen]

Opened new issues to replace this in #397 and #398 to be able to track our progress a little bit more granularly.

I'm making the decision not to open an issue for printing a progress bar -- I think that's a fool's errand, unless a Transfer API maintainer demonstrates a reliable way of determining real % progress.