Aidan Feldman

I think this might be a duplicate of https://github.com/executablebooks/MyST-Parser/issues/564.

> refactor every resource to use already already-initialized client instead of creating one per operation Is there an issue where we can follow that?

> at a minimum we want plugins to support linux64, win64 and osx. https://github.com/cloudfoundry/cli-plugin-repo#cross-compile-to-the-3-different-operating-systems That means this is blocked by #38, yeah?

Creating that tunnel does allow you to run multiple commands, e.g. from the MySQL prompt. Is this more about being able to let those run in the background?

An alternative is pushing a dedicated (small) app for the tunneling, to reduce the likelihood that the app is messed with while the user is tunneling through it. I assume...

We could make it optional...? Or just leave it as is. Not _that_ big of an inconvenience.

[Conduit](https://github.com/alphagov/paas-cf-conduit)'s approach is to [push a small static app](https://github.com/alphagov/paas-cf-conduit/blob/e8d58942e04e9427e04d50704771d2a17077b33e/conduit.go#L128-L130) that is used for the tunneling, then [bind the service(s)](https://github.com/alphagov/paas-cf-conduit/blob/e8d58942e04e9427e04d50704771d2a17077b33e/conduit.go#L179-L182) to it.

Hmm. There isn't, but I would accept a pull request for it. You saw the disclaimer recommending Autopilot, yeah? 😉

For sensitive environment variables, I recommend user-provided service instances. On Mon, Dec 5, 2016 at 12:40 PM Nathan Friedly wrote: > Yea, but in my case I want to use...

For [the main application I work on](https://github.com/18F/C2), for example, the `manifest` isn't complete, so (as it stands) we couldn't use that approach. While maybe not ideal, I imagine this is...