Expert Texture Home Contact me About Subscribe Digipede Connect on LinkedIn rwandering on Twitter rwandering on FriendFeed

The blogged wandering of Robert W. Anderson

Narrowing the Semantic Gap

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.

Tags: , , , ,

Why a SnapIn for the Command-Line?

On Tuesday I posted about the new Digipede SnapIn for PowerShell. 

One question I didn’t get into is, why write a SnapIn when PowerShell supports full scripting for .NET APIs?  The short answer is that we can provide a better command-line experience with PowerShell cmdlets than the “out of the box” PowerShell experience.  Windows PowerShell Architect, Jeffrey Snover, did a great post on this a few months back: Cmdlets vs. APIs

I thought I’d give an example of the difference as it relates to the new Digipede SnapIn. 

For example,  suppose you want to enumerate the pools on a Digipede Network.  Natively in PowerShell, you can do the following:

[System.Reflection.Assembly]::LoadFrom("C:\\Program Files\\Digipede" +
  "\\Framework SDK\\v2.0\\Net2.0\\Digipede.Framework.dll")
$DigipedeClient = New-Object -TypeName Digipede.Framework.Api.DigipedeClient
$DigipedeClient.Management.GetPools() | ft 

That is pretty verbose (note the first line is split in two to improve readability in my blog). This same operation becomes much simpler with the Digipede SnapIn:

Add-PSSnapIn DigipedeSnapIn
$DigipedeClient = New-DNClient -Network MYSERVER

And what about the output?  Without any extra information, PowerShell will format output on its own — a very cool feature.  The former example produces a default table output:

IsReadO  PoolId Name    Descrip Collect Schedul Potenti TotalCo JobTota TaskTot
    nly                 tion    ion     ingAlgo   alGhz mputeRe lComple alCompl
                                          rithm         sources     ted    eted
-------  ------ ----    ------- ------- ------- ------- ------- ------- -------
   True       1 Mast... Mast... {Mas... ...rity      66      19     665   57584
   True     601 Fifo            {Mas... ...tOut      18       3       0       0

PowerShell can’t determine which properties should be included, so it makes a guess.  The DigipedeSnapIn includes formatting information to give much more readable (and useful) default output:

PoolId Name                 Description                    Resources Potential
------ ----                 -----------                    --------- ---------
     1 Master Pool          Master Pool                           19        66
   601 Fifo                                                        3        18 

So, the SnapIn definitely provides a better command-line experience.  And the great thing?  These two worlds are not mutually exclusive.  For example, suppose you want to specify the default pool for a DigipedeClient object?  We haven’t exposed that as a property on New-DNClient nor provided a cmdlet for this purpose, but the API includes the PoolId property.  Just do this:

$DigipedeClient.PoolId = (Get-DNPool -Name "Fifo").PoolId

Now, the default pool is a pool named “FIFO”.

This brings me back to something I wrote in my previous post:  PowerShell is cool.

Tags: , , , ,

PowerShell SnapIn for the Digipede Network

deetle2ps Today we posted a preview of our PowerShell SnapIn for the Digipede Network — go to the Digipede community site for details and download instructions.

This preview provides a functioning command-line interface to much of the available Digipede Network management APIs.  This functionality will continue to be enhanced along with the underlying APIs (more on this in a future post).

This preview is a little bit of a departure for us at Digipede.  While we have targeted previews to customers in the past, this is the first time we have made one publicly available.  A bigger departure, though, is that we are also including full source code to this preview.

Digipede is not open-source, so why release the SnapIn code?

  • The SnapIn provides excellent examples for the Digipede Management APIs.  The SnapIn is also a good example of a PowerShell SnapIn.
  • By providing a sample as a SnapIn we are reducing the startup costs for our customers to develop their own cmdlets (for the Digipede Network and otherwise).
  • We hope that some community members will provide feedback in the form of suggestions, fixes and maybe even new cmdlets — this will help make the SnapIn better faster. 

Another question might be, why do a PowerShell SnapIn at all?  After all, PowerShell does a great job with .NET APIs without any additional support.

  • PowerShell does do an excellent job with .NET APIs (and COM APIs too, for that matter).  But this support is better suited to scripting than to a great command-line interface.  I will post an example of this difference later this week.
  • For some customers, a command-line interface is important.  PowerShell provides a standard framework into which such interfaces can be built — the days of writing one’s own custom command-line interfaces are thankfully past.
  • PowerShell is really cool.

If you are interested in PowerShell, the Digipede API, or a command-line interface to the Digipede Network, please take the time to try out the preview.  We would love to get feedback from you on what else it needs, any problems you find, and ideas for other cmdlets — implementations even better!

To learn more about Windows PowerShell, visit the Microsoft Windows PowerShell home page as well as the PowerShell Team blog.

Tags: , , , ,