On Oct 18, 2013, at 6:08 AM, Uri Shachar <[email protected]> wrote:
> On Thu, 17 Oct 2013 15:49:19 -0700 James Peach wrote: >> On Oct 17, 2013, at 3:23 PM, Uri Shachar <[email protected]> wrote: >>> On Thu, 17 Oct 2013 11:45:41 -0700 James Peach wrote: >>>> On Oct 13, 2013, at 2:15 PM, Uri Shachar <[email protected]> wrote: >>>>> On Wed, 9 Oct 2013 10:41:42 -0700 James Peach wrote: >>>>>> On Oct 8, 2013, at 1:19 PM, [email protected] wrote: >>>>>> >>>>>>> Updated Branches: >>>>>>> refs/heads/master 7ba121c9a -> 3c0c835c1 >>>>>>> >>>>>>> >>>>>>> TS-2268 Add support for opening protocol traffic sockets through the >>>>>>> traffic_manager. >>>>>> >> There's some interesting features that you are talking about here. I'd like >> to bring the discussion back to the specific API. Does this API help us get >> there? What can we do to address the concerns that I raised about it? > > I think we've reached an agreement on most of your concerns - the only item > you raised which is still somewhat open is allowing protocol plugins to sit > after the SSL engine. I feel that implementing this properly (with full > support for plugin chaining, maybe even converting the SSL engine into a > protocol plugin) is beyond the scope of this change, and it is not required > to make the new API useful. > (I'm all for it - just not in this context). > > As discussed - I'm going to change TSPluginDescriptorAccept(cont) into > TSNamedAccept(STRING, cont) and add a "name" tag to the port descriptors so > you'd configure 8085:plugin:name=myplugin:tr-full in > proxy.config.http.server_ports (I want to separate the name from the "plugin > accept" functionality to allow for future extensions). API-wise that sounds fine. Perhaps TSNamedAccept is a uncomfortably close to TSNetAcceptNamedProtocol. How about TSNetAcceptNamedDescriptor()? Implementation-wise, is this still going to be implemented as a TransportType? I think that it should be a separate property on HttpProxyPort so that you can accept on SSL and other transport types. J
