[j-nsp] router-jockeys and gui tools

[Phil Shafer]

[hijacking part of a thread from Keegan]

Keegan Holley writes:
>My gut says this is as much a product of Space being new as the general skeptcisim most 
>router-jockeys have towards GUI/WebUI based management tools.

As the on-box CLI developer, this has always been an area of interest
to me.  My gut says the router-jockey/gui repulsion is powered by:

a) completeness
   Everything one can do with a router is available in the CLI,
   where GUIs tend to carry a subset and will have a time lag
   WRT availability.  Part of this is driven by the tool-makers
   view of how their particular customer set works, and part
   is driven by the need to attack the biggest and most visible
   problems.

b) text/email friendly
   Pasting config into email and using "show | compare" allow
   simple obvious differences.  Diffing the output of two
   HTML divs is, well, difficult.

c) power tools
   If you want to repeat a command, "^P" is blindingly fast.
   Add in bindings like ESC-. and ESC-/ (and ^R) and you can
   get many jobs done faster at a CLI than in a GUI.

d) trust
   If I say "set interfaces xe-0/0/0 family inet filter output foo",
   then I know exacly what I did and how it will work.  When the GUI has
   a field/drop-down and I select "foo", I'm trusting the app to do
   the right thing, and to let me know when it cannot.

e) inertia
   I completely understand inertia.  I'm writing this email using
   vi under mh, chiefly because no one can pull the procmail needle
   from my arm.  Tools are addictive.  If they work, you use them
   more.  If they don't, you use them less.

Even in the face of these factors, there's definitely movement in
the GUI arena.  As tools evolve and are able to show more data and
as the volume of data demands tools that let you explore (not just
view) data, we need to find ways to keep the valuable portions of
the CLI world, while allowing data access for web tools.  Visualization
is becoming more important, and as someone who tried to make
Sparklines in ascii for op script output, I can definitely say that
the tty-based CLI is very limiting.

In JUNOS, we've had our XML APIs for >13 years, and the tight binding
between the CLI and the API ensure that feature parity is constant
and consistent.  We're working to find ways to expand on this, and
while I don't have anything to share yet, I'd love to hear back (on
or off list) regarding the items listed above and any additional
factors that keep you committed to the CLI with a loyalty that would
do Charlton Heston proud.

Thanks,
 Phil