Do we want to pull Hyperbahn specific logic into it's own client like Node & Go?

hyperbahn_sample.py

from tchannel import TChannel, Hyperbahn

tchannel = TChannel('my-service')

tchannel.listen()  # or

hyperbahn = Hyperbahn(tchannel)
hyperbahn.advertise()

Like the sync client & testing, let's keep it in the same repository till we hit 1.0

Go has a similar design: https://github.com/uber/tchannel/blob/master/golang/hyperbahn/client.go#L64

As does Node: https://github.com/uber/tchannel/blob/master/node/hyperbahn/index.js#L100

Or, with inheritance:

from tchannel import Hyperbahn

hyperbahn = Hyperbahn('my-service')
hyperbahn.advertise()

This has the benefit of representing the same public API with additional methods.

hyperbahn.raw()
hyperbahn.json()
hyperbahn.thrift()

I don't find that this abuses inheritance.

Let's be consistent with node/go.

I'll look more into it.

From what I can tell, this is consistent with Go & Node:

In app.py:

from tchannel import TChannel, Hyperbahn

tchannel = TChannel('my-service')
hyperbahn = Hyperbahn(tchannel)
hyperbahn.advertise()

In endpoint.py or some service layer class:

from app import tchannel

tchannel.thrift(...)

So in summary you compose a TChannel in to a Hyperbahn and call advertise instead of listen, and then continue to use the tchannel object. I think this will work in Python since everything is a reference.

Corbin seems to think we need to consider sub-channels, so I'll bang my head against the design a bit more so we don't get it wrong.