Question about RsFolder parameters about reportingservicestools HOT 2 CLOSED

We had a long debate with @SQLvariant about it and he consulted with additional MVPs and decided that was the more intuitive name for it as in some places you have the path for the local disk folder and then the RsFolder for those in SSRS, a good example for that case is Write-RsCatalogItem

from reportingservicestools.

Hm ... well, intuitive is a rather subjective thing. I'm one person, you asked many, so odds are you're right on that front (especially considering that I'm not the core audience for this module, coming very much from the PowerShell - rather than the dba - side of things).

However you now have created a naming conflict:

• When targeting folders versus targeting content elements in RS (such as individual catalog items).
• You've still got the path/itempath aliases, both for folders as well as content (unless you are willing to commit serious breaking changes)
• You'll still conflict with the file system parameters (only now it's the aliases conflicting, rather than the main name). Would have gone with 'OutputPath' and 'InputPath' for the FS paths, given how they are the exception, not the rule.

I'll still argue it's the worse approach, even from an intuition perspective, because now people have to relearn habits:

• Dbas will have to learn that the rest of PowerShell uses 'path' for paths, when they want to apply their PowerShell skills to something other than Reporting Services.
• PowerShell users that have to pick up Reporting Services have to get used to the other terminology
  (The fact, that aliases exist helps in not breaking existing scripts, however they are a lot worse to discover, so in most cases they won't help with interactive human usage).

Ah well, done is done, but now that I've had my say I can take it with equanimity ;)

Cheers,
Fred

from reportingservicestools.