This is a reasonable concern, but the reality is that:

  $ telnet google.com 80
  GET / HTTP/1.0

Is just going to become:

  >>> use SPDY;
  >>> SPDY->dump('http://www.google.com/);

Plain-text formats have always been slower for things that are not plain text. But even 30 years ago, when computers were even slower, Unix designers decided plain text was still the way to go, because it was easier to debug and easier for humans to work with. No specialized tools required, no poring over hex dumps. HTML won over other document formats. JSON and XML won over other binary formats. Any coder can look at JSON and see what is being transferred, without the aid of anything but a text editor. Plain-text marshalling formats for binary data (e.g., base64) are still useful for pasting data into an email or adding ssh keys to authorized_keys with "cat >>".

This is perhaps a long way of saying that I don't expect that having tool support makes SPDY any nicer.

Less true for tcp dumps

which I believe was the previous poster intention since he mentioned wire shark..

Also piping bunch of unix command will suffer a little of they

swig + libpcap should get you there for any mainstream language (assuming you're on a real OS.)

SPDY is always encrypted, so it would be more fair to compare it with HTTPS, where you can't do anything like that anyway.

Sure you can. openssl s_client -connect google.com:443

Not sure what the equivalent is on windows though.

Sure, but that's not telnet. I would assume you could make a similar tool for debugging SPDY too.

not surprisingly it's... openssl s_client -connect google.com:443

They probably won't switch off http support before a very long time :) So you won't miss anything.

Sigh. Those who abandon Unix principles deserve whatever they get.

Efficiency. You can keep your Unix principled autoconf scripts, thank you.