Last week, PowerShell Architect Jeffrey Snover wrote an excellent post titled the Semantic Gap.  He writes about the gap as . . .

. . . 2 worlds:

1. The world as we think about it.
2. The world as we can manipulate it.

The difference between these two is what is called the semantic gap. 

This is a great working definition. 

Jeff writes about this specifically regarding PowerShell and instrumentation providers and asks the question,

So why do instrumentation providers close or not close the semantic gap?

Yes, some do, and some don’t.  This isn’t just about hierarchy of needs, but also about prioritization.  How important to the provider is a narrow semantic gap for product X when used through interface Y? 

In the case of X := Digipede Network and Y:= PowerShell, we thought it pretty important.

But how do you decide if narrowing the gap is worth it?  Engineering costs aside, understanding what your interface could look like in PowerShell can help you decide.  Internally, we answered these questions:

1. What would a PowerShell script look like just using your .NET or COM APIs? 
2. What could it look like with Cmdlets? 
3. Would these Cmdlets support how we think about the Digipede Network (i.e., small gap?).

I already said the answer to #3 turned out to be yes and in a previous post, I gave an example of the gap in Why a SnapIn for the Command-Line?  This example highlights the gap for a common operation on the Digipede Network: get the description of a pool of resources.

If you are thinking about supporting PowerShell in your product, take a look at my post.

I hope this helps you decide.