RFC - RE: Pipeline input. How should this be handled?

[ArtisanByteCrafter]

All exposed functions should accept pipeline input. In order to accomplish this the traditional Powershell way, objects in the pipeline should have the properties expected by the funtions being piped to, however the API returns objects one level higher than that. Changing this output would be a major breaking change, and should be considered very carefully.

There are two options:

1) Leave output alone and simply query one level deep before piping:

$query = Get-SmaMachineInventory .....
$Query.Machines | Set-SmaMachineInventory ....

Advantages:

• No breaking change needed

Disadvantages:

• Contrary to best practice in pipeline input
• Would cause confusion for those expecting traditional pipeline behavior

2) Format output to remove top-level parameters Count and Warning, and only return results:

Get-SmaMachineInventory .... | Set-SmaMachinenventory ....

Advantages:

• Best practice in handling pipeline input
• Could take advantage of pipeline parallelism to improve performance on longer queries

Disadvantages:

• Major breaking change. Any scripts that use syntax like $Query.Machines to retrieve objects would need to be re-written to simply use $Query. This would apply to all endpoints.
• Note Properties Count and Warnings would not be returned with the request, although traditional count methods would still be easily usable. (.count , | Measure-Object, etc.)

I'm leaning towards a phased approach, i.e. enabling pipeline input like in option 1, so as not to break anything, then at some point in the future, simply making the switch to v2 after a warning has been out for a while.

[ArtisanByteCrafter]

This is now implemented as of 1580db5