At that point I think most people would just quit their jobs.
When the world marches ahead while you stay behind you build technical debt. The further you fall behind the more effort it will take to catch up.
To put it another way, businesses (and individuals!) that can't stay current will become history. It's just a matter of time.
Of course, I'd do my best to make sure it is fast and completely transparent to the user.
First things first though... An authorization framework, shared bookmarks, terminal session sharing, and a special secret surprise that will hopefully be cool enough to make the news again.
The package comes with an interactive tutorial on how to embed Gate One into other applications. It's in the tests directory, "hello_embedded".
UPDATE: Hangman is now working. Huzzah!
If you like the ADTD part you should run the demo and hit 'q' for a special surprise =D
So run Gate One locally: https://localhost/
I use it like that every day!
Hmmm... Not sure why Hangman isn't working. I'll fix it (not a priority). I suspect that I forgot to copy its word dictionary into the chroot jail.
That's because the demo is inside of a chroot jail and the user it runs as only has read-only access to its home directory. Also, the version of vim running is actually rvim which doesn't let you execute shell commands (for good reason).
If you figure out a way to break out of the jail let me know so I can close that hole!
Just an FYI: You can't inspect SSL packets without a MitM attack. Some proxies support this (Blue Coat) but none of them work with WebSockets. So as it stands right now it is impossible to sniff your Gate One session unless you're using a very weak SSL certificate.
Whoever is looking at your Gate One traffic in a sniffer will only see a destination and a source IP. They won't even see the URLs you're hitting.
Yes, the terminal emulator in Gate One is server-side (terminal.py). It converts the terminal's screen to HTML before sending it to the client. Actually, it only sends lines to the client that have been updated but that part is handled separate from the terminal emulator.
There's actually a pretty good overview of the differences between server and client-side terminal emulation here: http://en.wikipedia.org/wiki/Web-based_SSH
Oh the pain of software keyboards! Believe me, it drives me crazy. Gate One will work in Mobile Firefox and Chrome for Android using a software keyboard but not very well. You're much better off using a hardware keyboard.
Having said that, here's how it currently works in Gate One with software keyboards: There's an invisible input element on the page that gets focus when you load the page or tap somewhere. When that happens the software keyboard comes up and you can enter your keystrokes. However, whenever you tap "go" the input element loses focus! This will drive you crazy. I have opened bugs for both Chrome and Firefox to get a workaround of some sort.
I am planning on writing a thin "native" client of sorts to use Gate One on mobile devices (probably using PhoneGap) just for the sole purpose of getting control over the software keyboard (make it stay open!).
Why would Gate One be Windows-only? It runs in a browser.
Don't think, "PuTTY replacement" or, "terminal replacement." Think, "I can use this from anywhere without having to install anything" or, "this could be embedded into an administration interface to provide a command line where previously there was none."
Though to be honest my end-goal with Gate One is to make it the best terminal emulator (and SSH client) ever. We've only begun to explore what's possible when you combine a terminal with capabilities of the browser (HTML5, specifically).
Now lets see an X11 implementation
It's in the roadmap. It's just a matter of priorities and time.
Well, I'm monitoring it in real-time. If the demo servers start getting overloaded I'll add more.
The two, 1GB Rackspace instances that were up when this news hit the front page are still running fine at this moment.