Hi, Kedar.
Kedar Mhaswade wrote:
> Hi Tim,
>
> Looking at the code, it's not clear to me how this can be leveraged
> unless
> the admin command takes an option like --upload. This is something I am
> struggling with. Before your code changes, --upload (and
> --deploymentplan)
> triggered an upload functionality. Has that remained the same after your
> changes?
For the moment, yes.
I have always been uncomfortable that the supposedly generic admin CLI
code had this baked-in dependency on a particular command's options.
I have in mind some ideas we should talk about for handling this in a
truly generic way that would indeed leverage the payload-related changes
I've checked in.
>
> Also, a few other questions:
>
> - What is a "payload"? Isn't it just a file or set of files?
It's an abstraction of the input or output stream content of the http
request or response.
> - How does the "download" work? Does the generic download of the
> so-called
> payload "save" the files in the payload on disk?
Yes. That code is already there in the CLIRemoteCommand logic that runs
after the response has arrived from the server. The server-side command
uses the Payload.Outbound side of things to populate the payload, using
the command options. The generic payload manager code in the remote
client recognizes if one or more parts of the response represent file
downloads and, if so, automatically saves them to the right place.
The "right place" is determined by the server-side command's
interpretation of its options (which, of course, it knows full well how
to do) and it sets characteristics of each part it places into the
payload back to the client so the client-side logic can handle the
downloaded files generically, without any coupling to the specific
options on any command.
- Tim