resending because I made a typo: hadoop -> hbase

We could do a split for ES much like the split that we do for hbase (098, 10 etc). have a janusgraph-es/janusgraph-es-core that JanusGraph uses, and shims like janusgraph-es1, janusgraph-es2-transport, and janusgraph-es5-jest. Since we are newly introducing 2.X support in the in-flight PR and the coding is already done, perhaps we only add transport support on es2 lineage and only support HTTP/jest on es5 lineage?

On Friday, March 3, 2017 at 12:40:07 AM UTC+9, Keith Lohnes wrote:

I started some conversation over at https://github.com/JanusGraph/janusgraph/pull/79#pullrequestreview-24343839, and Jason Plurad suggested I move that over here. 

I have some code that's been used in a Titan deployment using the apache licensed Jest ES http client. There was some discussion in that PR about whether to continue to support the Transport/node client in there as well.

The key points of the conversation there

1. Versions to support (1.x, 2.x, 5.x)

   With the Jest client, we could support all three pretty easily. 1 vs 2.x and 5.x would be changing the .jar out.  There's some open PRs in the Jest repo that need to get merged for 5.x support, but once those are and we update the jar version, we'd be able to support 5.x. Maintaining 1.x support for a little while would be nice for people with production Titan instances, as Adam Phelps pointed out. 1.x and 2.x could use the same code, they just need different jars.

2. HTTP vs Transport/Node

    I think in #92 there's a mention of Transport being deprecated. My first instinct is to say that Janus should mark Transport/Node as deprecated and continue to support Transport/Node clients until a major version release at which point support could be removed.  I have some work done to split out the Transport/Node clients from the Http client, and make for an easy removal once that decision has been made.