
Introducing Google Cloud Shell’s new code editor - rafaelm
https://cloudplatform.googleblog.com/2016/10/introducing-Google-Cloud-Shels-new-code-editor.html?m=1
======
cm3
Not criticizing the project, genuinely curious:

It's great that browsers can achieve more functionality previously exclusive
to native applications, but anytime a code editor written in JavaScript to be
run in a browser is announced, I wonder one thing: why don't we try to come up
with a client/server protocol that would allow you to use your local editor,
which is already fully customized to your needs? Is the idea that the files
being edited are remote and therefore the only thing that would make sense is
improving extensions like "It' All Text!" or wasavi?

It ought to be enough if one can trigger opening a buffer in a local editor,
which accesses a local webserver provided by your browser, backed by the
textarea, and having a means of updating the textarea on save via a POST
issued from, say, Emacs to Firefox's textarea-httpd.

~~~
LoSboccacc
Well, the idea is sound, but the timing is wrong. we're past company caring
about interoperability, i.e. compare FTP vs WebDAV.

There won't be new open protocols to exchange data for a long while as the
whole tech scene is built around growing as a monopoly of a sector.

~~~
amelius
Sad but true. Any ideas what may turn the tide?

~~~
sytse
At GitLab we're exploring an idea that may turn the tide. I agree that online
editors don't seem the way forward. The problems are:

\- People have wildly different preferences (TextMate, Sublime, Atom, VScode,
vim, emacs, etc.)

\- It is really hard to get an online IDE right. The most advanced version is
probably Eclipse Che and they have an API to do autosuggest by looking in all
the files.

Also see [https://gitlab.com/gitlab-org/gitlab-
ce/issues/22863](https://gitlab.com/gitlab-org/gitlab-ce/issues/22863)

"It ought to be enough if one can trigger opening a buffer in a local editor,
which accesses a local webserver provided by your browser, backed by the
textarea, and having a means of updating the textarea on save via a POST
issued from, say, Emacs to Firefox's textarea-httpd."

I think the better approach is to sync the entire directory so you can do
global search and replace and autosuggest.

My idea of how to make the IDE sync work:

1\. You click on an icon in GitLab, it is next to where we now show the url
for the terminal.

2\. The icon opens a url, with a schema specific for our solution (although we
should open source the protocol so others can reuse it). In the url is the
following information: server and project location, pod and container to
connect to, a token to identify the user.

3\. Beforehand the user has installed a local client that is registered to
handle this type of schema.

4\. The filesystem of the container is synched to the users machine by the
local client (I propose to a default directory system specific to the local
client).

5\. The local client also opens up the favorite editor of the user (make this
configurable with smart default by seeing what editors are installed via
which).

6\. The local editor talks to an endpoint of GitLab, similar to how our
terminal works.

7\. GitLab uses kubernetes/docker exec to run unison and fswatch on the
container (this is a different approach that the volume approach suggested in
[https://github.com/leighmcculloch/docker-
unison#docker](https://github.com/leighmcculloch/docker-unison#docker) ).

8\. GitLab makes a reference implementation of this for MacOS, using unison
and fswatch. The community will hopefully make Linux and Windows clients.

What do people think?

Also see [https://gitlab.com/gitlab-org/gitlab-
ce/issues/22876](https://gitlab.com/gitlab-org/gitlab-ce/issues/22876)

~~~
TylerJewell
Hi - I am the project lead for Eclipse Che. While I'd love to take credit for
a special API for handling intellisense with languages, we didn't do it alone.
We had a proprietary API that we built over a number of years that distributed
intellisense using JSON. But when we saw Microsoft's VS Code doing something
very similar but for local services, we consolidated into a single "Language
Server Protocol" that we announced with Microsoft and RedHat earlier this
year. This allows any IDE to plugin to any language. Languages have to provide
their own language server implementation that matches the JSON protocol.

In Eclipse Che, we package these language servers for distribution into
dynamically deployed agents. so when you start a workspace, your workspace can
add a "PHP agent", for example and then we will deploy the language server and
then hook up the browser IDE to the language server. To the end user, it feels
seamless, but we actually install the language server for them. There are
something like 2 dozen languages being built for language servers now. Rust
just announced theirs and others are working on C/C++/RAML - even Emacs is
getting one. RedHat is working on an advanced Java version and we use CSharp
and eventually typescript from Microsoft. We want total interop with VS Code.
Eventually Eclipse Orion (an editor) and Eclipse IDE (desktop IDE) will add
support.

With Eclipse Che, we provide a simple CLI that lets you live sync your
workspace to your desktop IDE. You just "che mount" and we use a fuse-based
file system with unison sync to keep the hosted workspaces synchronized with
the desktop. You can then use your local IDE and still have your workspaces
entirely in the cloud.

These language servers must have access to the project file system, and we are
handling that by either embedding the language server into the same container
as the workspace, but since we now support compose workspaces where a
workspace can be many containers, we are moving all of the language servers to
run as separately deployed agent containers. When a user requests a language
intellisense, we'll deploy for that workspace an agent container which is
volume mounted to the projects in the workspace containers, so that the
workspace can have the utilties needed.

~~~
sytse
Thanks for the background Tyler. The Language Server Protocol is certainly
interesting. We've linked this comment from [https://gitlab.com/gitlab-
org/gitlab-ce/issues/22876#note_17...](https://gitlab.com/gitlab-org/gitlab-
ce/issues/22876#note_17189231) let's continue the conversation there.

------
nawtacawp
Orion.

[https://www.orionhub.org](https://www.orionhub.org)

~~~
citruspi
I get

> {"Severity":"Error","Message":"Hosted site www.orionhub.org is
> stopped","HttpCode":404,"BundleId":"org.eclipse.orion.server.core","Code":0}

when I go to that page.

This[0] one seems to work for me.

[0]:
[https://orionhub.org/mixloginstatic/landing.html](https://orionhub.org/mixloginstatic/landing.html)

------
VOYD
Wasn't this the plot line the movie "Antitrust" \-
[https://en.wikipedia.org/wiki/Antitrust_(film)](https://en.wikipedia.org/wiki/Antitrust_\(film\))
? ;)

------
wiradikusuma
"Code" but doesn't mention programming languages they support. I assume it's
Java, PHP, Python and Go, since they are all officially supported (in Google
App Engine).

In case Google Cloud engineer is here: What about debugger support for other
JVM languages?

~~~
thesandlord
[https://cloud.google.com/shell/docs/features#tools](https://cloud.google.com/shell/docs/features#tools)

Cloud Shell is just a Debian VM with full root access. You can install
anything you want (but note only the HOME directory is persistent)

------
kordless
Error: Could not connect to Cloud Shell on port 8085. Ensure your server is
listening on port 8085 and try again.

------
cantbecool
Isn't this like Heroku Garden?

[http://i.imgur.com/EOH6zY2.jpg](http://i.imgur.com/EOH6zY2.jpg)

------
Hydraulix989
There's a million UX annoyances with Google Cloud that still need fixed, and
the very first thing they do is build an editor...

~~~
firasd
I've only been using it for the last few months but the UI has struck me as
more pleasant than Azure or AWS.

~~~
drusepth
To be fair, I'm not sure how UI could be _worse_ than AWS's... :P

------
jclulow
> We’ve heard from a lot of Google Cloud Platform (GCP) users that they like
> to edit code and configuration files without leaving their browser.

Who are these people? The _last_ thing I want is to depend on a browser for
additional critical things that I do all the time.

~~~
moondev
It's pretty convienent to be able to access all of your tools and environment
from any modern browser with internet in the world.

~~~
swiley
It's significantly more convenient to be able to access them from ssh anywhere
in the world.

~~~
Klathmon
And yet on many platforms an additional program is required for SSH, the UX is
terrible on mobile devices, and you'd better hope you have your keys with you.

A browser is on literally everything by default, works on all platforms, and
is more convenient for many.

~~~
falcolas
I'm having trouble imagining doing serious development work on a mobile
device. Even basic bugfixes would be better done with a computer tethered to a
phone if the lack of wifi is an issue.

