Merge branch 'master' into extensive_tutorial

.gitignore

@@ -1 +1,2 @@
 .DS_Store
+.idea

CHANGELOG.md

@@ -0,0 +1,12 @@
+## v1.4.4
+
+ENHANCEMENTS:
+
+* client: increase level of plugin exit logs [[GH-195](https://github.com/hashicorp/go-plugin/pull/195)]
+
+BUG FIXES:
+
+* Bidirectional communication: fix bidirectional communication when AutoMTLS is enabled [[GH-193](https://github.com/hashicorp/go-plugin/pull/193)]
+* RPC: Trim a spurious log message for plugins using RPC [[GH-186](https://github.com/hashicorp/go-plugin/pull/186)]
+
+

README.md

@@ -3,8 +3,9 @@
 `go-plugin` is a Go (golang) plugin system over RPC. It is the plugin system
 that has been in use by HashiCorp tooling for over 4 years. While initially
 created for [Packer](https://www.packer.io), it is additionally in use by
-[Terraform](https://www.terraform.io), [Nomad](https://www.nomadproject.io), and
-[Vault](https://www.vaultproject.io).
+[Terraform](https://www.terraform.io), [Nomad](https://www.nomadproject.io),
+[Vault](https://www.vaultproject.io), and
+[Boundary](https://www.boundaryproject.io).
 
 While the plugin system is over RPC, it is currently only designed to work
 over a local [reliable] network. Plugins over a real network are not supported
@@ -109,7 +110,7 @@ high-level steps that must be done. Examples are available in the
   1. Choose the interface(s) you want to expose for plugins.
 
   2. For each interface, implement an implementation of that interface
-     that communicates over a `net/rpc` connection or other a
+     that communicates over a `net/rpc` connection or over a
      [gRPC](http://www.grpc.io) connection or both. You'll have to implement
      both a client and server implementation.
 
@@ -141,28 +142,23 @@ This plugin system will give host processes a system for constraining
 versions. This is in addition to the protocol versioning already present
 which is more for larger underlying changes.
 
-**Plugin fetching.** We will integrate with [go-getter](https://github.com/hashicorp/go-getter)
-to support automatic download + install of plugins. Paired with cryptographically
-secure plugins (above), we can make this a safe operation for an amazing
-user experience.
-
 ## What About Shared Libraries?
 
 When we started using plugins (late 2012, early 2013), plugins over RPC
 were the only option since Go didn't support dynamic library loading. Today,
-Go still doesn't support dynamic library loading, but they do intend to.
-Since 2012, our plugin system has stabilized from millions of users using it,
-and has many benefits we've come to value greatly.
-
-For example, we intend to use this plugin system in
-[Vault](https://www.vaultproject.io), and dynamic library loading will
-simply never be acceptable in Vault for security reasons. That is an extreme
+Go supports the [plugin](https://golang.org/pkg/plugin/) standard library with
+a number of  limitations. Since 2012, our plugin system has stabilized 
+from tens of millions of users using it, and has many benefits we've come to 
+value greatly.
+
+For example, we use this plugin system in
+[Vault](https://www.vaultproject.io) where dynamic library loading is
+not acceptable for security reasons. That is an extreme
 example, but we believe our library system has more upsides than downsides
 over dynamic library loading and since we've had it built and tested for years,
-we'll likely continue to use it.
+we'll continue to use it.
 
 Shared libraries have one major advantage over our system which is much
 higher performance. In real world scenarios across our various tools,
 we've never required any more performance out of our plugin system and it
 has seen very high throughput, so this isn't a concern for us at the moment.
-