PowerShell / PowerShell-RFC

RFC (Request for Comments) documents for community feedback on design changes and improvements to PowerShell ecosystem
MIT License
432 stars 123 forks source link

Add RFC for PSRemoting providers #347

Closed jborean93 closed 1 year ago

SteveL-MSFT commented 1 year ago

The @PowerShell/powershell-committee discussed this. We agree there's utility to having a simpler one-line experience. However, we have some concerns on how this would work with different authentication unless they all only use a Credential object (whether it only requires the username or also the password).

In the end, we believe a Invoke-RemoteCommand cmdlet could be published as a community module that implements the behavior described in this RFC without needing to making engine changes to accommodate nor increase the parameterset burden for Invoke-Command. In fact, this would be an opportunity to improve the parameters experience (used by Invoke-Command) without being a breaking change. As part of that module, it would have a Register-RemoteScheme that registers ssh://foo.com to a specific PSSession module/cmdlet.

PaulHigin commented 1 year ago

I like this idea of consolidating remoting connections (custom and built-in) into Invoke-Command, via a registration scheme and prefixes to host name parameter arguments. But Invoke-Command is so overloaded with legacy parameter sets, that it feels better to start fresh with a new command/cmdlet designed specifically for this purpose (invoking command/scripts remotely over arbitrary remote connections). It could do a better job handling various and upcoming authentication schemes. The downside is that it would be in a separate module that users would have to download, possibly slowing down adoption. But I think there is enough value here where users would take the extra work in including it in their module tool set.

gaelcolas commented 1 year ago

So by saying "we probably shouldn't change the built-in command because it's overloaded with legacy parameter sets", aren't you saying "this command has been depreciated, investment should be made in a new module implementing this RFC so that we can eventually deprecate the legacy command and remove from the code base, achieving the goal of smaller footprint & better modularity"? In which case, saying it out loud would be nice, or explaining why this cannot happen would also be nice.