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

rwandering.net

The blogged wandering of Robert W. Anderson

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.SetUrlFromHost("MYSERVER")
$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
Get-DNPool

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
                                                                          GHzH
------ ----                 -----------                    --------- ---------
     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: , , , ,

    Trackback

1 Comment »

    Expert Texture » Narrowing the Semantic Gap wrote @ February 20th, 2008 at 6:39 pm

[...] 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 [...]

Your comment

HTML-Tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>