From 902fb621665a430a917333be59f6f8fc20412e73 Mon Sep 17 00:00:00 2001
From: Larry McQueary <larry@apcera.com>
Date: Fri, 10 Mar 2017 13:25:36 -0700
Subject: [PATCH] Add ROADMAP.md (#448)

* Add initial ROADMAP.md
---
 ROADMAP.md | 91 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 91 insertions(+)
 create mode 100644 ROADMAP.md

diff --git a/ROADMAP.md b/ROADMAP.md
new file mode 100644
index 00000000..7fd87217
--- /dev/null
+++ b/ROADMAP.md
@@ -0,0 +1,91 @@
+# Roadmap [DRAFT]
+
+This is the roadmap for the NATS Server. The purpose of this document is to give insight into some of
+the major features we plan to implement in the near future. It is a living document, and will change
+ as goals and milestones are completed and new plans are made.
+
+This project's release plan is kept updated on [the wiki](https://github.com/nats-io/gnatsd/wiki).
+
+A master project release plan for all NATS projects can be found
+[here](https://github.com/nats-io/roadmap/wiki)
+
+### Planning and Tracking
+
+An [Open-Source Planning Process](https://github.com/nats-io/gnatsd/wiki/Open-Source-Planning-Process) is 
+used to define the Roadmap. 
+
+This project is managed via GitHub [milestones](https://github.com/nats-io/gnatsd/milestones). 
+[Project Pages](https://github.com/nats-io/gnatsd/wiki) define the 
+goals for each Milestone and identify current progress.
+
+Upcoming features and bugfixes will be added to the relevant milestone. One or more Milestones will
+ in turn be assigned to a release.
+If a feature or bugfix is not part of a milestone, it is currently unscheduled for implementation. 
+
+### Short Term
+
+#### "Hot" configuration reload
+
+We will enable changes to a subset of configuration items on a running `gnatsd` without requiring
+the instance to be restarted.  
+  
+See [Issue #338](https://github.com/nats-io/gnatsd/issues/338)
+  
+#### Integrate Promethus support 
+
+We have done some work recently on exporting NATS monitoring data via Promethus. We plan to 
+share this work in an upcoming release.
+ 
+See [Issue #345](https://github.com/nats-io/gnatsd/issues/345)
+
+
+### Further Out
+
+#### Enable external authentication and authorization via extensible auth provider 
+
+We will improve/extend the auth interface(s) and configuration to support external auth endpoints.
+
+See [Issue #434](https://github.com/nats-io/gnatsd/issues/434)
+
+#### Namespace isolation by account/organization
+
+Multi-tenancy is a popular discussion topic, and one of the requirements we often hear is for the 
+ability to isolate/encapsulate the subject namespace by "tenant" (e.g. an account or organization). 
+For example, messages published on `FOO.BAR` by tenant A would not be visible to tenant B's 
+subscribers on `FOO.BAR`, and vice versa. We'd like to support this in an efficient and performant way. 
+
+See [Issue #347](https://github.com/nats-io/gnatsd/issues/347) and [Issue #348](https://github.com/nats-io/gnatsd/issues/348)
+
+#### Rate limiting
+
+Another multi-tenancy concern is the ability to limit the rate at which publishers can publish messages
+to `gnatsd`. We've implemented this in a branch for an internal project but would like to make it public soon.
+ 
+See [Issue #346](https://github.com/nats-io/gnatsd/issues/346)
+
+#### Make auto-unsubscribe atomic to the SUB protocol
+
+Right now auto-unsubscribe is two operations: `SUB foo 1` followed by `UNSUB foo 1 1` (unsubscribe 
+after 1 message). For the sake of simplicty, efficiency and usability, we'd like to make that an 
+atomic protocol operation, optionally specifying the limit as part of the subscription e.g. `SUB foo 1 1`
+
+See [Issue #344](https://github.com/nats-io/gnatsd/issues/344)
+
+#### Rename `gnatsd` to `nats-server`
+
+The original Ruby-based NATS server (now retired) was called `nats-server`, and the newer Go 
+version needed a unique name, hence `gnatsd`. We've recently gone through and attempted to 
+normalize names across all NATS projects to make them more predictable. Renaming `gnatsd` to 
+`nats-server` would align it more closely with the rest of the components in the NATS family.
+ 
+See See [Issue #226](https://github.com/nats-io/gnatsd/issues/226)
+
+#### Client pruning/rebalancing
+
+Now that cluster auto-discovery is implemented for both clients and servers, NATS clusters can 
+be dynamically expanded on demand. When this happens, it would be useful to (optionally) re-balance
+ the client connections across the new (larger) cluster.
+ 
+ See See [Issue #343](https://github.com/nats-io/gnatsd/issues/343)
+ 
+ 
\ No newline at end of file