Chrome App Migration?

[bgiesing]

In case you haven't seen yet @rpwoodbu, Google is discontinuing Chrome apps on every platform except Chrome OS. Any plans for this? Google says devs should convert it to either Progressive Web Apps or native packaging with Electron/NW.js.

https://developers.chrome.com/apps/migration

[rpwoodbu]

I am aware of this (have been for some time), and have given it some consideration. The target for this app is Chrome OS, and Packaged Apps will be supported there "for the foreseeable future". So for Chrome OS users, this is a non-issue.

However, I was surprised to discover that a large contingent of users are on Windows, for which there is no native Mosh solution. This wasn't my target for this app, but I'm happy they have been served. It therefore deserves some effort to look into what we can do for them.

The reason that this is a Packaged App is primarily because I needed access to the chrome.sockets.udp API, which was only available to them (at the time, anyway). Mosh will only work as a Chrome Extension if that API is available there. A cursory glance at the extension APIs isn't promising.

So Mosh for Chrome's future may only be a Packaged App, and Windows users will have to find an alternative. (Consider that Android apps are coming to all Chrome platforms; maybe we should all just run JuiceSSH?) We might be able to convince the Chrome folks to give extensions chrome.sockets.udp access; after all, they're asking for suggestions (see "let us know" link here; I've already posted, but maybe more posts will increase the SNR).

[bgiesing]

@rpwoodbu

So Mosh for Chrome's future may only be a Packaged App, and Windows users will have to find an alternative. (Consider that Android apps are coming to all Chrome platforms; maybe we should all just run JuiceSSH?)

Android apps aren't coming to all platforms, there also Chrome OS exclusive as the new way they do it (via Play Store) works by hooking a subsystem and converting kernel calls (like Bash on Windows 10 does) so it is impossible on other platforms. The old method (ARC) uses Chrome apps so that also will no longer work on non-Chrome OS devices.

The reason that this is a Packaged App is primarily because I needed access to the chrome.sockets.udp API, which was only available to them (at the time, anyway). Mosh will only work as a Chrome Extension if that API is available there. A cursory glance at the extension APIs isn't promising.

NW.js (one of the native packaging methods Google suggests) supports all chrome.* app APIs so you should just be able to package the current app as is with NW.js and it will run exactly like Chrome. http://nwjs.io/blog/chrome-apps-support/

[rpwoodbu]

Android apps aren't coming to all platforms...

Oh, OK... I guess I wasn't paying close enough attention. Seems odd to me that they're keeping Chrome Apps and adding Android apps just on Chrome OS. :-/

Packaging Mosh for Chrome into a native app is madness. It makes way more sense to get the upstream Mosh building for Windows. I hear that Windows 10 has Linux ABI compatibility or some such, so maybe this isn't all that hard anymore?

[keithw]

We're basically there; see microsoft/WSL#170 and mobile-shell/mosh#781.

I haven't used Windows recently, but honestly my sense is that Mosh-for-Chrome-on-Windows is a nicer UX today than native Mosh is likely to be, since you bundle Mosh with a good terminal emulator and you have a nice distribution story (the Chrome App store, etc.) and can distribute updates, etc. (I feel the same way about Mosh-on-Cygwin, which does work today.) But it is an option and maybe the next-best one if Mosh-for-Chrome does end up becoming ChromeOS only. :-(

[bgiesing]

@rpwoodbu Yeah and even Android apps aren't coming to all Chrome OS devices. I have both the CR-48 and Samsung Chromebook (the original one), neither getting it. Heck you could say that's because how old they are but Google has stated that only "roughly half" of devices in the past 2 years are going to be supported (even the 1st gen Chromebook Pixel by Google itself isn't supported).

As for the native app madness, as @keithw said,

Mosh-for-Chrome-on-Windows is a nicer UX today than native Mosh is likely to be

I don't know if you have access to a non-Chromebook machine but I would look at NW.js as I said in the previous reply as it's basically 100% compatible with all chrome APIs so the app should run the exact same (just without having Chrome open/installed) and to test, all you have to do is download it from their site and drag the unpacked extension folder onto nw.exe. I haven't tried it with this yet but I did with Authy and you can't even notice a difference.

[rpwoodbu]

@keithw:

Re UX: Well, maybe the bundle is better. But if I were on Windows, I'd be pretty happy to fire up a Bash shell in some sort of xterm-esque thing and type mosh. That's the same UX as on *nix, and I don't hear folks complaining.

Re distribution of updates: Unfortunately, that's going away. I'd be producing a true native Windows app that folks would download and install. (At least that's how I understand it at this point.) It'd be more like Mosh-for-Windows-with-Chromium-Baggage.

@bgiesing:

Interesting it is that simple. I don't have a Windows machine, but I may give that a shot in Linux as a proof-of-concept. I still think it is kinda nuts, though, and I'm not particularly keen on maintaining a Windows version, which would need to be tested at each release (again, I have no Windows machine, and don't plan on it). If folks really want this, I'm happy for it to live in this project, and do the work to teach the build system how to bundle this up, but someone else will have to be the release engineer.

[keithw]

@rpwoodbu: Agreed that maintaining a whole Chromium+Mosh app for Windows seems like a pain. Of course I'll defer to you on what you think is best. I have filled out the "let us know" form and included a link to this issue.

[roryst]

hell i even use mosh for chrome in linux. sometimes odd things happen on my end with xfce4-terminal 0.6.3 (debian stretch) where the returned line will be invisible until i hit another key. don't have this problem with mosh for chrome. example:

[cgull]

Alas, Windows Subsystem for Linux is not going to be a complete solution to this problem. It requires enabling Windows 10's developer mode, which a lot of Mosh's developer/ops audience will be happy to do. But that involves some security tradeoffs and will probably be blocked by many corporate Windows security policies.

Windows support really boils down to some having somebody with the interest and aptitude for Windows development to do a Mosh port or wrapper for the Windows environment. Nobody has really done that yet. Somebody did an incomplete Win32 port some years back. It looks fundamentally OK, but the code had diverged too much from the Mosh code to be brought in as-is, and it would need work to improve performance and finish the GUI. If someone were to improve it, either as contributions back to Mosh or as a fork, it would make a lot of people happy.

Also: packaging a web/JS UI + JS terminal emulation + Mosh C++ binary into an app may be madness, but that's exactly what https://github.com/blinksh/blink is, on iOS.

[rpwoodbu]

OK, color me impressed. It just works. All I did was build the ZIP file just as I would ordinarily to give to the Chrome Web Store, and started it like so:

$ ./nw mosh_chrome_dev.zip

The only caveat is that you have to use the SDK "flavor" of NW.js, otherwise you don't get the NaCl goodness.

I haven't tried this on Windows yet, because, well, I don't have Windows. I'll seek help with that shortly. But I have no reason to believe it won't work just as well.

This is madness, but low-hanging madness, so into the madness we shall go! 😉

[rpwoodbu]

I have confirmation that this works on Windows. I will spend some time seeing if I can teach Bazel (the build system I'm using) how to make an MSI package. There's a thing for Linux called msitools which looks quite promising.

[bgiesing]

@rpwoodbu Most people don't use MSIs anymore but EXEs.

Here's NW.js' page saying how to package http://docs.nwjs.io/en/latest/For%20Users/Package%20and%20Distribute/

[rpwoodbu]

@bgiesing I've read that page and I believe I understand it. It doesn't talk at all about MSI vs. any other technique. It just suggests a few packaging facilities, including Windows Installer (which IIUC is what is used with an MSI, but could also be used with an EXE).

I have no intention of undertaking the task of writing a Win32/64 app, much less cross-compiling from Linux to Win32/64, and I am surely not going to do any builds on Windows, so no EXE. I'll see about producing an MSI, but if I get frustrated, all I might offer is a ZIP file and some instructions; I think I can do a little better for Windows users than that, though. Others can improve upon this later if they so desire, but I would really like to avoid needing to build on Windows.

[bgiesing]

@rpwoodbu MSI is a Windows installer but EXE doesn't have to be a native app so MSI or EXE would be the exact same essentally. I just said use EXE instead as some people don't know what MSIs are and might not know how to use it. (Some users are ridiculous) Also EXEs can be used with other install systems than Windows Installer (like Nullsoft or 7zip)

This is an easy way to look at installers:

1. A custom, third-party installation system in an EXE file.
2. A Windows Installer installation in an MSI file.
3. An EXE file that bootstraps an MSI file (that may be embedded inside the EXE file).

[rpwoodbu]

I don't have time for all that. No third-party installers. I am 95% confident I can build a working MSI from Linux without bringing in a ton of dependencies. That's as far as I'm willing to take it (and as I've mentioned, I'll punt on it if it becomes trouble).

I am going to need help, though, doing ongoing release qualification and whatnot. Whoever takes on that task may also want to improve the installer. Might you (@bgiesing) be interested in that? I think that if I get the build system to produce an MSI, you'd have a good foundation. I will, however, require that it build in Linux, and be gentle with external dependencies (which may preclude a third-party installer; I'll have to see).

But in my opinion, I just don't think users are going to care if the file ends in EXE or MSI; they're just going to double-click whatever they download.

Oh and BTW, I'd sure be interested to know if it is feasible to do any sort of automatic distribution and update (I hear there's a Windows Store or some such). I don't know how that works, or what the restrictions on the app might be, but if you know something about this, please share.

[roryst]

how about this?
"Koush, developer of the Chrome app Vysor (among other projects), has made porting Chrome apps to Electron incredibly easy. With his tool, aptly named Electron Chrome, developers can compile their existing Chrome apps into Electron applications in seconds. It essentially works as a compatibility layer that takes Chrome API calls and translates them into Electron API calls."

http://www.androidpolice.com/2016/08/28/moving-chrome-apps-desktop-apps-now-easy-thanks-electron-chrome/

[rpwoodbu]

@MarkyBob Interesting idea. I like that it is smaller to distribute than NW.js. I especially like that electron-chrome can pull apps from the Chrome Web Store, which would retain the auto-update functionality. However, it doesn't appear that it supports all the APIs I need (notably, chrome.sockets.udp). And it isn't clear from a cursory glance whether it would support NaCl (fill me in on that if you know). I'm also a little worried that I'd run into more friction with compatibility issues, since it is translating calls to its own runtime instead of just using Chromium, but I'd be willing to give it a shot once/if it supports the APIs I need.

I've made some progress on the Windows installer front; more to come soon.

[rpwoodbu]

I have an initial effort done now. I will publish the installer files when I produce v0.3.7 (I have a couple of unrelated things I need to get in first). There may be issues (there's one KI already) or feature requests; please open new issues for these.

[rpwoodbu]

Here are dev releases of v0.3.7 for both x64 and ia32:

https://storage.googleapis.com/mosh-chrome/mosh_for_windows_0.3.7-dev_x64.msi
https://storage.googleapis.com/mosh-chrome/mosh_for_windows_0.3.7-dev_ia32.msi

I haven't tested on ia32, so if anyone can do that, it'd be especially helpful.

When I do the next stable release, I'll publish the Windows installers on GitHub under Releases.

[cgull]

Huh, I thought I commented already. Something close to 20 days ago, I tried the ia32 build on a tablet with Win10 32-bit (worked fine) and an old laptop with Vista (failed on a missing DLL symbol, apparently this is due to Chrome and this derived environment having dropped support for Windows <= Vista).
I am impressed, this is an easy single-package install with no dependencies for Windows users. Once it gets to a stable/release version, I'm tempted to recommend it as the Windows solution on the Mosh web page, if you're OK with whatever extra support burden you might get.

[rpwoodbu]

Thanks, @cgull, for testing it, and for the nice words. I am prepared for the extra support burden; I wouldn't have gone to this trouble if I didn't want folks to use it. 😉 But at the same time, if anyone produces a better alternative, I'd happily ditch this Windows "port" (if you can even call it that).

[daveme88]

Very happy to have found some sort of native windows mosh.
It seems to be working (limited testing so far)
Only problem is that it seems to only allow one session.
Once its running starting it again does nothing.
Would really like multiple sessions.

[rpwoodbu]

@daveme88 Thanks for the note about multiple sessions. This was brought up in Issue #137 for OS X, but I closed it as I'm not aiming to support OS X long-term. I've reopened that issue, though, as it also affects Windows.